Building accessible web components without tears

• Four painful questions
  • have you tried to navigate your site with only keyboard?
  • could you perform every action on that site? (everyone put there hand down)
  • did the tab order make sense?
  • did you always see the element in focus?
• “full stack” devs seems to have forgotten some of the fundamentals of the web
• paragraphs, headings are terminal block elements: they can’t contain other block elements
• accessibility: enables hearing impaired, vision impaired, motor impaired users and more to access the web.
• accessibility: allows your users to use their input device of choice. More than keyboards, mouses and screen-readers
• WAI ARIA: Web accessibility initiative, accessible rich internet applications
• We can use roles and states to describe the elements to assistive technologies
• Screen readers require notification when content changes within the document using aria-live
• aria-live can be used for anything is intended to be used for important information: error alerts, resorting tables
• aria-live has three values: off, polite and assertive
  • off: will wait until the screen reader loops over the content
  • polite: will notify the user after the current action finishes
  • assertive: is poorly supported but in theory will interupt the current action
• role=alert is used to tell a user of really important
• Two main modes screen readers use:
  • read mode, standard mode can navigate the page
  • forms mode, can interact with form elements… but there is a catch… content that is not directly related to the form (eg p tags with alert messages) will not be read-aloud.
• Form control error messages can be inaccessible, if it is not programatically related to the field (again, in a p-tag)
  • we can not use colour alone to define a form field is invalid
  • the error message needs to be programatically linked to the form
  • including the error message inside the label is a simple method of associating
• when submitting forms, if an error occurs the user should be focused to the top of the form where there will be a description of the form
• A good wrapper for errors prepares the page for the error while keeping them invisible to users
• models have problems
  • keyboard users can tab outside the model, the model is active and it can be confusing
  • screen readers may not be notified of the model
  • screen readers may not be made aware of the purpose of the model
  • closing the model may move the user away from the locations in which they navigated to the model
• fixing models
  • hide the model from assistive technologies, once they open hide the pages remaining content
  • set focus to the model itself, not content within the model
  • limit the tab key to the model for keyboard navigation
  • explain to the user what each element will do when they close a model, submit a form in the model, etc.
  • make a smart decision about where to position the user once the model closees

Models are shit but we can make them less shit

• in page tabs
  • relationship between tabs and each panels content may not be clear
  • keyboard only navigation may not work on tabs
  • tab and arrow navigation (arrow to choose tab to display) is preferred
  • define the tabs as role=tabpanel, links as role=tab
  • define tab as aria-selelected=true/false, panel as aria-hidden
• there is a lot to do around accessibility, but there are quick wins available to make the application accessible.
• don’t be overwhelmed
• this to do
  • test with keyboard only
  • test with one or more screen-readers
  • test screen-readers in different browsers, different bugs appear in diff browsers
  • get specialists in to help you
• the ideal time to focus on accessibility is when you’re building the individual components, when you’re building pattern libraries.