Interview with Léonie Watson: How accessibility influences the work of developers and designer

As a diamond sponsor of the Frontend Conference Zurich on 27 and 28 August, we had the exclusive opportunity to conduct interviews with selected speakers. You shared your experiences and opinions about the exciting interplay between design and technology. Thank you for the inspirational food for thought!

Léonie Watson (@leoniewatson) – Senior Accessibility Engineer with The Paciello Group (TPG) and owner of LJWatson Consulting. About Léonie Watson.

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?

Until the early 00s the web was fairly static. HTML, CSS, DOM and JavaScript hadn’t changed all that much since they were first released, and they all had good accessibility built in. Web content was also static and relatively simple, and once loaded into the browser it didn’t change without a full page refresh. There were accessibility problems, but they too tended to be fairly simple – missing text descriptions, broken heading hierarchies, layout tables etc.

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.

Is the tendency to move functionality from the server to the client (using JavaScript) a risk or a chance?

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.

2017 – Trends, business cases and strategic steps

Customer expectations are higher than ever before: In the course of purchase decisions, the experience factor is becoming more important than the price or specific product characteristics (Customer 2020, Walker). Therefore, we are convinced that in 2017, in order to increase commitment to their brand, companies will have to take a closer look at how they inspire their customers in the digital world.

Virtual DOM and a predictable state


Virtual DOM based libraries where you work with a declarative UI, using components and not direct DOM access like in the past, and Flux libraries that gave us a predictable state to work with, are arguably the two most important innovations of recent years in frontend app development.