Screen-Reader and Keyboard
Navigation Accessibility Powered by AI

• When a popup appears, the keyboard focus must lift off the main page and land back down within the first clickable element of the popup.


• Navigating using the Tab key within the popup must loop back to start when reaching the last element and trying to move forward.


• Users must be able to close popups with the Esc key, and the focus must go back to the element that was focused on prior to the popup.


• Popups must include a “role” attribute equal to “dialog”.


• Popups must include an “aria-modal” attribute equal to “true”.

•  “NAV” tag or a “role” attribute equal to “navigation/menu/menubar” (depends on the menu type) must be present on the top element that contains all the links and menu items (role=”navigation/menu/menubar”).


• A “role” attribute equal to “menuitem” must be present on the links that comprise the menu items.


• Users can use the Tab key to navigate to the next element, and Shift+Tab to navigate to the previous element, and the focused element must be easily identifiable using a focus ring (outline).


• Users can navigate across the menu bar itself using the left-and-right keyboard arrows. When reaching the end of the menu, and pressing the forward arrow key, the navigation should loop back to the first item.

• Users can open dropdowns using the Enter and the arrow-down keys. Dropdowns should also be opened by focusing on the menu item.


• Users can navigate within dropdowns using the up-and-down arrows, and the focus must never escape and loop within the dropdown unless it was intentionally closed.


• Users can close the dropdown using the Esc key, and the keyboard focus must go back to the root menu item of this dropdown.

• Buttons must contain text, title, or an aria-label.


• Must be an actual “BUTTON” tag or alternatively, a “role” attribute that equals to “button” is present.


• Buttons must include text/aria-label/title.

• All fields must include a “LABEL” tag that is connected to the field by the “id” and the “for” attributes, or an “aria-label” attribute.


• Required fields must include both visual cues (Asterix*, text or other), and the “aria-required” attribute equals true.


• Fields must include the “aria-invalid” attribute to inform screen-readers whether the field is currently valid or invalid. This attribute must change dynamically according to the validations. E.g. an empty required “name” field must include aria-invalid=”true” to indicate that it’s invalid, but change to aria-invalid=”false” once the user fills it up.


• When a form is submitted and errors are present, the keyboard focus must be taken to the first invalid field, and the user must receive an explanation (both visual and to the screen-reader) of what the issue is with this field.


• When a form is submitted successfully, a blind user with a screen-reader should be informed of that using an alert element or via other means.

All images must have an Alt attribute (some people call it a tag although it’s really an attribute), that properly describes the objects in the image, and if the image contains texts (like typical banners) then the embedded text must also be present in the alt attribute.

Icons don’t really have much of a guideline, because there isn’t such a thing as an “ICON” tag or element. Icons are usually being used with links or buttons, to describe some kind of action. So, the requirements for making icons accessible is pretty much the same as making links and buttons compliant. Every icon must include a description of Its purpose or action.

• Must include text, title, or an aria-label.


• Must be logically ordered within the document (a “read more” must come after the title and the paragraph of a section, for example).


• Links must be reachable by keyboard navigation using the Tab key.


• Links must provide a visual indicator if they are opened in a new window, and also announce that to a screen-reader using a hidden text or title.


• Links must be noticeable on-page and look different than regular text.