The State of Accessibility

I recently had a chance to sit down with Nektarios Paisios, who is a software engineer on the Chrome Accessibility team, to hear his thoughts on the current state of accessibility (a11y). You can watch the 30 minute video below, but I wanted to write up a summary of the important points because they bear repeating.

There are many great takeaways to come out of the interview so I hope this post makes them easier to find.

"You may have a fast website with the best content, but it's all for nothing if people can't actually use it"

How would you describe accessibility to someone who may be new to web development?

• we should see a11y as a feature of our website
• the more accessible a website is, the more usable it is for everyone
• it doesn't just affect people with disabilities (15% of population)
• you will get more customers if your site is accessible
• "it's a good business practice, it's the right thing to do, but also it creates the best experience for everybody"

What are the various ways people with disabilities use the web?

• screen readers used by the visually impaired
• magnifiers are used to enlarge text, videos, or images for the partially sighted
• captions and audio transcriptions are used for the hearing impaired
• a switch axis device is used for people with motor disabilities to move through interface at the flip of a switch
• eye tracking can also be used to move the cursor around the screen
• there are lots of accommodations depending on people's needs

What advice would you give to people who may be more experienced developers?

• companies use the web as an extension of their brand, they want to be unique and stand apart
• but people don't want to learn a new way to use the web because the website is so unique
• top-down navigation (eg tab) may produce unexpected results
• different workflows for different websites put up barriers for users who need to re-learn workflows
• users have muscle memory, eg they may press a switch a specific number of times to go somewhere, but when websites try to be too different they may (accidentally) break expectations
• tip: follow existing conventions!
• realize that not everyone uses a mouse or touchscreen
• people may be using commands through assistive software, which may be hard to work with your website
• there are lots of accessibility standards, WCAG most prominent -- familiarize yourself with the standards and follow guidelines to ensure you're consistent with established patterns like keyboard navigation
• tip: actually test your website using assistive software to understand the bottlenecks!
• eg chromebooks come with screen readers and other tools are available like magnification, color filtering, android volume button simulates switch axis

What would you say to developers who may be well-intentioned yet overly descriptive in their ARIA attributes?

• keep it simple, rely on context, eg "minify" on a video is self-explanatory based on context
• don't assume the user is unable to comprehend a simple concept like minimization of a video and over-compensate with verbose descriptions
• use simple language, don't use complex words
• also don't just rely on tab key for keyboard navigation -- "tab is not the only key on the keyboard"
• ARIA provides many shortcut keys. tab is just one.

How can semantic markup help assistive software to understand the contents of the page?

• eg <input type="email"> conveys semantic meaning and enables helpful suggestions (same for date types, listbox, etc)
• use these hints unless you have a really good reason not to
• it may be hard to customize/stylize a built-in form control, but they come with useful semantics that should be preserved

How have the ways people with disabilities use the web changed over time?

• people with disabilities feel liberated by web applications
• for example, in the physical world there are physical limitations like stairs, not to mention there are people who may have prejudices against people with disabilities
• websites do not have physical limitations or biases, they treat all users the same
• disabled people can perform tasks via a computer not traditionally possible, eg secretary duties, enabling new employment opportunities
• when you're using the same websites and web apps as everybody else, you feel included, like you're treated the same
• on the other hand, there's a responsibility on web developers to address a11y challenges
• in physical world, real people can see that someone is having difficulty and help accordingly, but websites and computers are inflexible

What are some of the standardization efforts, for example by the Web Accessibility Initiative (WAI)?

• the ARIA guidelines are extensive, defines specific attrs you can add to HTML that enables elements to inherit semantic meaning (eg, button or checkbox functionality)
• checkboxes convey state visually (checked or not), but this must also be conveyed non-visually through data attributes like aria-checked for screen readers to understand it
• the web components standard enables accessible widgets to be packaged up and used across web apps, proliferating usability
• the Accessibility Object Model (AOM) enables web apps to expose a11y info and perform some a11y actions that were only available to native applications, eg a user gesture/command could be communicated to the web app itself, which can take the appropriate action
• the AOM defines a way to provide semantically equivalent a11y alternatives to graphical UI, eg canvas

What are the tools available to developers to understand how accessible a web page is?

• Chrome has several a11y tools built-in
• DevTools has an Accessibility tab in the Elements panel
• the A11y tab includes the a11y tree, which is based on the DOM tree and layout tree, it conveys info about the page to assistive software
• the Audits panel includes Lighthouse, which has a11y audits, and recommends things that need improvement
• Lighthouse doesn't catch all errors, manual testing is always needed, but it still provides helpful results
• remember: a score of 100% doesn't imply full a11y
• HTTP Archive collects stats about Lighthouse scores from millions of pages: median A11y score 62%, 42% of pages correctly use the alt attr, 12% of pages correctly label form elements
• the data shows lots of room for improvement, we need to redouble efforts and consider using automated solutions
• pay attention to WCAG: content is perceivable (describe images, captions for videos, simplified alternate text, rapid animations disabled, etc), website is robust (HTML is validated, use correct attrs, form fields have labels, etc)
• standards can be vague or overly technical, so developers who want to learn more about a11y can find videos of people using assistive technology to put themselves in others shoes

How do we move the web forward without leaving people with disabilities behind? (eg AR/VR)

• difficult to wait for gradual progress, eg touchscreens may be unusable
• people should get a career or degree in a11y, push the boundaries
• get creative with a11y, provide new solutions

Additional resources for people who want to make the web more accessible

• Overview of the W3C Web Content Accessibility Guidelines (WCAG)
• WCAG 2.1 recommendations
• Free accessibility Udacity webinar by Google
• Accessibility guides on web.dev
• Rob Dodson's A11ycast video series
• Accessibility report on HTTP Archive
• Video: The importance of accessibility in product design
• Video: 3 tips when designing for accessibility