basics of accessibility

why make things accessible?

  • let's say 0.3% of your userbase is blind. Those individuals are 100% unable to use your site
  • there's no good way to automate testing an inaccessible site

basics of accessibility for automated testing

lets say you want to test your login feature. you need to type a username into the username box, a password into the password box, and click login.

selecting the username box based on id is a bad idea: it changes arbitrarily, but moreso because it doesn't reflect how the user interacts with the app. when filling out forms, the user selects an input based on its label; likewise with assistive technology. by using that selector in our tests, we can more closely model how the user interacts with the app.

you can't select login purely by text, because your header says login; and you can't select it by input type='submit' because yesterday it was a div onClick={submitForm} and tomorrow it'll be button onClick={_ => setSubmitting(true)}. what remains the same is the element's "role", the system visual of affordances that says "click me and something'll happen", ie "i am a button". those affordances are visual for the functionally sighted, but we communicate that to the browser, testing software, and assistive technology with the element's "role".

finally, we click on the element with the role "button" and name "login".

that's why everyone tells you to use the correct html element: it automatically sets the element's role. in scenarios where it's better to use divs, or we break things up & confuse the browser, we have to manually specify the element's role.

99.9% of the time the name is going to be right.

a list of all roles is available here:

web accessibility is a great deal more complicated than just giving things the correct roles and names, but these are good enough for test automation.

lets say you're writing a test and you want to see what's available. in chromium, open devtools and get out the element selector. your accessibility tree is to the right of the html, in the same tablist as 'Styles'. in firefox, open devtools, select the accessibility tab, then the element selector. mouse over anything.

in chromium, you'll see the element's contrast, name, role, and whether it's keyboard focusable. in firefox what subset of those you see is context dependent. you're also going to see a lot of errors, everywhere on the web.

lets say you're putting together a feature you want to make more testable. mouse over everything and ask "is this generic? or is this a button, a menu, an article?", "is this a textbox? or is it better described as a searchbox?", and, especially, "is this a link or a button?": because it's probably a button.

more information here