Not long ago you stated: “Once upon a time, accessibility had a reputation problem. It wasn’t cool, and it certainly wasn’t sexy.” What characterizes accessibility today? What changed?
For too long the accessibility community took a very negative approach to communicating with designers and developers. It was common for reports to be published, pointing out the accessibility failures of websites and applications. Every talk about accessibility focused on guidelines and legislation, and why you couldn’t do something or other because it was bad for accessibility.
Then people started to realise there was a better way to do things. Now accessibility is considered a standard part of the design/development toolkit. Talks now focus on practical implementation, and ways to solve accessibility challenges without compromising on creativity or innovation. Accessibility is now a regular topic at conferences like O’Reilly Fluent, Future of Web Design, Generate Web Directions, and of course FrontEnd conference!
Designers and developers around the world now take responsibility for creating interfaces that can be used by everyone, and they rightly take pride in getting accessibility right. At the end of the day, we all put time and effort into creating things for people to enjoy using, and (to use a favourite phrase of mine) we design like we give a damn!
In recent years, has the web become more accessible or rather less?
Since then the web has grown increasingly complex. HTML5, CSS3, DOM3/4 and ES5/6 have made it possible to create more interactive and engaging interfaces. With this increased complexity there is much more to think about in terms of accessibility. The advent of new interaction paradigms like touch, and the more common use of speech/voice interaction, has also added to the accessibility challenge.
So accessibility is probably in a holding pattern for the time-being. It could be worse, but it could also be better, and as designers and developers we’re working hard to make that happen. We’re developing solutions for accessibility problems, like using ARIA to make interfaces more accessible to screen reader users for example.
In itself, moving functionality to the client isn’t an accessibility problem. It introduces some new accessibility considerations, like managing focus in single-page applications, making sure assistive technology users are aware when content has updated on the page etc. But if you get the accessibility right, then the real considerations are things like security and resilience.
The rise of frameworks like Angular, Ember and Bootstrap has introduced some fairly serious accessibility challenges. Few frameworks have good accessibility built-in, and in many cases it isn’t easy for developers to know how or where to make changes to the code. A handful of developers are working on the more popular frameworks to improve accessibility, but there is a lot of work to do – and I encourage anyone with time to contribute accessibility patches to their favourite frameworks.
Do browser vendors provide developers with the necessary tools and capabilities or could they do more to increase accessibility?
Browsers expose accessibility information through the available platform accessibility APIs. These APIs include information about the role, name and state of HTML elements and controls in the interface. Most browsers except Edge have dev tools that make it possible to inspect the accessibility information being exposed to assistive technologies – specifically the ability to walk the accessibility tree (a subset of the DOM tree) created by the browser.
For the moment these tools tend to be separate from the standard dev tools. It would be good to see the accessibility tools being incorporated into the general dev tools more – something the Chrome team at Google is looking at doing soon I believe.
Specs and implementations are moving very fast (at least some of them). What are you most excited about?
Web Components are exciting. We’ll have the ability to prototype proposed new HTML elements for usability and accessibility, before they’re introduced into the specification. There are accessibility challenges with Web Components too. When we create new HTML elements or controls, the accessibility has to be created from scratch – keyboard interaction, semantic information like role, name and state all have to be provided.
It’s also an interesting time for HTML. The W3C has created the Web Platform Incubator Community Group (WICG), as a place for developers to suggest and discuss new ideas for HTML, DOM and other platform specifications. Ideas will feed into the proposed Web Platform Working Group, which I’ll be delighted to be co-chairing when the time comes!
The goal of the WICG is to get more people involved in the standards process – developers who use these technologies every-day, and who have ideas for new features, elements and capabilities. There’s a real buzz around this, and we’re already starting to see some innovative ideas being discussed for future inclusion in HTML, CSS and other specifications.