Theme
ARIA
Roles, attributes and names that assistive technology can actually use. 16 automated checks Websight runs, plus 1 axe rule it does not run, each with a live example and a fix you can copy.
ARIA attributes must be allowed for the element's role
aria-allowed-attrEvery ARIA role comes with a short list of attributes it understands. aria-checked belongs on a checkbox, aria-pressed on a toggle button, aria-valuenow on a slider. Put an attribute on a role that does not support it and the browser either drops it or passes on something that makes no sense, so the control looks right on screen but is announced wrong.aria-braillelabel must have a matching text labelaria-braille-equivalentaria-braillelabel and aria-brailleroledescription let you give a braille display a shorter or contracted version of a control's name or role. They sit on top of the ordinary name, they do not replace it. If the element has a braille label but no accessible name, speech users get nothing at all and braille users get a label with no fallback.ARIA attributes must follow the conditions of the element's rolearia-conditional-attrA few ARIA attributes are allowed on a role only under conditions. The ones you will actually meet: aria-checked on a native input type=checkbox must agree with the checked state (and is best left off), and aria-level, aria-posinset and aria-setsize on a row only make sense inside a treegrid. Break the condition and the browser has two stories about the same control.Deprecated ARIA roles must not be usedaria-deprecated-roleARIA retires roles from time to time. A deprecated role is still in the specification so old pages do not break, but authors are told to stop using it and browsers may stop giving it any special meaning. The one most people meet is role="directory", once used for a table of contents. A plain list, usually inside a nav with a label, does the job better.aria-label must not be used on div, span or p without a rolearia-prohibited-attraria-label and aria-labelledby only work on elements that can have a name: controls, landmarks, images, headings, tables and similar. On a plain div, span or p (and on a handful of roles like paragraph, code and presentation) they are prohibited. Browsers mostly ignore them there, so a label that looks helpful in the source is never spoken.Required ARIA attributes must be provided for the rolearia-required-attrSome ARIA roles only make sense with a state or value attached. A switch is on or off (aria-checked), a slider is at a number (aria-valuenow), a heading has a level (aria-level), a combobox is open or closed (aria-expanded). Give an element the role without the attribute and a screen reader can say what it is but not what it is doing, which is the half that mattered.ARIA roles that need particular children must contain themaria-required-childrenSome roles are containers that only mean something with the right children inside: listbox and option, tablist and tab, menu and menuitem, tree and treeitem, table and row. If the children are plain divs, the screen reader sees a listbox with nothing in it, even though three choices are clearly on screen.ARIA roles that need a particular parent must sit inside itaria-required-parentSome roles only make sense inside a particular parent. A menuitem lives in a menu or menubar, an option in a listbox, a tab in a tablist, a treeitem in a tree, a row in a table, grid or treegrid. Put the child role on an element with no such parent and the screen reader cannot say how many there are, which one this is, or how to move between them.aria-roledescription must only be used on elements with a rolearia-roledescriptionaria-roledescription lets you swap the word a screen reader uses for a role: say slide instead of group, or page instead of tab panel. It only works on an element that has a role, either from the role attribute or from the element itself. On a bare div it is ignored. Use it sparingly, with plain words a person would recognise, because it also hides the standard role that people have learnt.ARIA roles must be validaria-rolesThe role attribute only accepts names from the ARIA list: dialog, button, tab, listbox and so on. A made-up value like role="modal", a typo like role="buton", or an abstract role like widget that exists only to organise the specification, is dropped by the browser. The element then falls back to whatever it was underneath, which for a div is nothing.Tabs must have an accessible namearia-tab-nameEvery element with role="tab" needs a name: the words a screen reader speaks when the tab gets focus and the words a voice control user says to pick it. Tabs built from text get their name for free. Tabs built from icons alone, or from an image with no alt, have no name, so the listener hears a count but never which tab is which.Tooltips must have an accessible namearia-tooltip-nameAn element with role="tooltip" needs a name, which is normally just the text inside it. The common way to break this is hiding that text with aria-hidden, or replacing it with an icon, so the tooltip has a role and a visible message but no accessible name. A screen reader then announces that a tooltip exists without saying what it says.ARIA attributes must have valid valuesaria-valid-attr-valueEach ARIA attribute accepts a particular kind of value: true or false, a number, a word from a short list, or the id of another element. Write yes instead of true, or point at an id that does not exist, and the browser ignores the attribute or treats it as something you did not intend. The attribute is spelt right, so the mistake is easy to miss in the source.ARIA attributes must have valid namesaria-valid-attrBrowsers only act on attribute names that exist in the ARIA specification. A near miss, like aria-labeledby with one l, is not an error anywhere; the page renders, the console is quiet, and the label simply never reaches anyone. This check catches attribute names that start with aria- but are not real.ids used by ARIA and labels must be uniqueduplicate-id-ariaaria-labelledby, aria-describedby, aria-controls and the label for attribute all work by id. An id is meant to appear once on a page. When it appears twice, the browser resolves every reference to the first one it finds, so the second field quietly borrows the first field's hint, label or panel. Nothing looks wrong on screen.Meters must have an accessible namearia-meter-namerole="meter" is for a measurement within a known range: password strength, disk space used, battery level. The role carries the number, but a screen reader also needs the name to say what the number is. Without it the listener hears a value floating free. The visible text beside the bar does not count unless it is linked with aria-labelledby.Progress bars must have an accessible namearia-progressbar-namerole="progressbar" tells a screen reader that something is in progress and how far along it is. It also needs a name saying what that something is: Uploading holiday-photos.zip, Step 2 of 4, Installing update. Without the name, the listener hears a percentage and nothing to attach it to, which is worse when several things are happening at once.Who these pages are for: the developer or site owner who has a scan result in front of them and wants to understand it, test it and fix it without a training course.
Keep going
Check your page for aria issues
Websight runs these checks on any page in Chrome and shows a draft fix for each element it finds.
Add Websight to ChromeFree scans, no account, nothing leaves your computer. Automated tools find only part of the problems; the extension says so on every report.