Building web accessibility for 2019
Today’s web content is amazingly rich. It varies from standard HTML to complex web apps full of media; such as animation, data visualization, video games, mixed reality and VR, to name a few. Such content is often inaccessible or poorly accessible, which means a broken user experience for those who rely on assistive technologies to interact with web sites. This experience, can be annoying at its best to empty web pages as its worst. Sometimes web authors even provide alternative content for these users. Needless to say, it’s not always equivalent. What alternative content for a video game is out there?
Websites are built inaccessible not only because rich media content is highly dynamic which makes it not trivial to describe its semantics but also because there’s no proper technology on the web to express such content semantics to the assistive technologies. You may wonder why, with all the technologies to create web content out there, why we do not have one to make it accessible? Here’s an explanation.
WEB STANDARDS
A key web technology to make content accessible is ARIA. ARIA stands for the Accessible Rich Internet Application. This is a web standard, which defines a collection of attributes you can place on a DOM element to specify role, properties and state. For example, <div role=”button” aria-disabled> will turn the HTML:div element into a disabled button semantically, what makes the assistive technologies users to perceive the div element as a button.
It’s fair to say that ARIA is generally recognized as a complete set of semantic annotations available to web developers. In other words ARIA shapes the web author’s vocabulary when it comes to accessibility.
ARIA is a remarkable technology indeed, and it has a good story of success. It enables a great number of websites to be accessible. There’s one important bit in this story though: ARIA vocabulary replicates HTML semantics at large. For sure, it provides a bunch of extra cool things, such as grid or tree controls, but it doesn’t let you go very far beyond.
So what If you have a use case that falls out standard HTML? First, you can work on alternative content that can be mapped into HTML. You may succeed or not, which depends on complexity of your case. And second, you can propose an ARIA extension. It’s not as bad as it may sound. There are good precedents, for example, ARIA-DPUB extension. I know it is a slow process, but it works. You’d better have a good weight in the industry though to make it happen.
PLATFORM APIs: GLANCE AT HISTORY
ARIA vocabulary is not the only problem. There’s another part of puzzle, which is no accessibility API was ever designed to expose such unalike content to the assistive technologies.
All accessibility APIs take their roots a couple of decades ago, when inaccessible JavaScript controls was a unique challenge to solve. Over time HTML has matured and evolved into HTML5, acquiring a hefty amount of new features. It urged accessibility API vendors to adjust APIs to make the new features accessible. Also some efforts were made to make graphical content accessible, such as SVG and HTML canvas drawings. However most, if not all initiatives, were purely inspired by HTML-like use cases.
In case of non HTML content, for example, math, no breakthrough happened. It seems no API vendors made any decent moves to address the problem at large. Agreed, there were some notable exceptions like OS X API, which has got extra properties for math, but you know the exception just proves the rule.
You can say it happens for a reason, such as there’s no great interest in a such low volume content — indeed, it requires to make vicious effort to push things forward and there’s always a bigger fish to fry. But the fact remains: the web authors expectations weren’t met. In consequence web authors tried to reuse existing know-hows to expose math content, which was mostly about generating human readable annotations, something like, “a plus b divided by zero”. Some screen readers started to parse MathML on their own in order to extract semantics. Needless to say, it is rather hacky workarounds, than neat solutions.
Admittedly, there has been good progress in making web accessible over the last decade. However, overall tendency was about bringing existing expertise to new platforms and technologies. It allowed to keep traditionally accessible content accessible, but it mostly left unaddressed all other kinds of content, both long-time acquaintances and newbies, popped out several years ago and sprouted throughout the modern web.
ACCESSIBILITY CONCEPTS
All accessibility APIs are built around similar concepts if not to say the same concepts. These concepts serve to allow the authors to describe and identify blocks of content and connect the blocks to each other. The browser exposes these blocks to the assistive technologies via accessibility APIs, and the assistive technologies transform them into a format that the users may perceive, understand and operate with.
Here’s a short overview of accessibility concepts for the sake of providing context. You may scroll down to the end of this chapter, if you feel bored :)
Role is a cornerstone concept in semantic description of a block. It is a primary characteristic of a block and serves to identify block’s type. For example, this is a button or this is a paragraph. It also scopes set of possible properties and states and defines behavioral patterns. For example, this is a selected menu item or this is a text field that can be focused. Or this is a grid cell; it has row and column indices, which helps the user to navigate the grid. Also a block may have a human readable label — the first thing the user will hear, when the focus lands on the block.
Another key concept is relations, which describe connections between the blocks, i.e. how the blocks relate to each other. For example, most of the blocks are connected via parent-child relations like grid and its grid cells. Or an error message, shown if the user mistyped a password, is connected to a password field. Relations allow the user to navigate back and forth between blocks depending on content type and its state at user’s discretion.
Last but not least concept is actions. It is behavioral concept, used to describe interactions the user may take on a block. If this is a button, for example, then you can click it and so on.
A long story short, a block is described by role, states and attributes, which allows the user to perceive the block. A block’s actions allow the user to interact with content, and relations are for navigation.
Also, web content may change over time, which means the blocks can be created or removed or altered, as well as relations between them. All the changes are piped to the assistive technologies via eventing mechanism of accessibility APIs. This is not a 100% separate accessibility concept, but it is an integral part worth to mention for the sake of further conversation.
UNIVERSAL LANGUAGE
You may find it surprising, but these concepts are universal enough to describe almost any kind of content, you can see on the web today. Indeed, as long as you can describe the content by words, you can fit these verbal descriptions into accessibility concepts — all you need is to name objects, list their properties, define relations, and to explain how to interact.
Need an example? Sure. Say, you have a pie chart — this is something that falls out standard HTML, and thus you typically have to use bunch of tricks to make it accessible. However the concepts make a perfect match here. Indeed, a pie itself is a role, its title is a label. A pie chart consists of sectors, each of them also has a title, and all sectors are connected by relations, defining which one goes next. So the user can read a pie chart by navigating all sectors one by one.
Or let’s consider a video game, where a teddy bear teaches you some dancing. The bear shows dancing moves like heel turn, heel pull, dos-a-dos. Cameras keep track of the position of you and estimate how well you perform. So in terms of the concepts, the bear’s instructions are blocks of a limited life cycle, with labels, which are narrated to you. Limb positions are another set of blocks, which are characterized by a scalar value, ranged from 0 to 100%, and describing how close you were to a desired position. So, as the bear dances, you are told “heel turn, heel pull” and as you move, you hear how perfect your movement was. You may also add feedback factor here, which will serve to advise how your movements can improved, something like try leaning forward more next time etc.
You shouldn’t limit yourself by these examples. Thinking to start online music sheets store? You don’t want to leave anyone behind for sure. You will need to make music¸notes accessible, so assistive technology users can also enjoy it. Does your web app use chemistry ring formulas or math equations or anything else from any other subject you can think of? So, you can definitely describe all those symbols and formulas to your friend, so your friend can understand those, right? Thus, you should be able to express those in accessibility concepts as well. You may want to practice on your own to see how it goes.
SHAPE THE IDEA
Let’s come back to earth.
The accessibility concepts were invented years ago, and surprisingly or not, they do have a good fit to the modern web. However, web authors still struggle to make web apps accessible. How does it come, you wonder, what piece is missing? The answer is rather straightforward: web authors don’t have a rightful technology to describe web content, or in webish terms, there is no appropriate tag names and attributes or JavaScript hooks suitable to describe meaning of the content. So let’s say you have created a web app, which looks terrific and quite useful, but your creativity was not limited to standard HTML. Chances are the machine has no idea what the app is about, and thus cannot successfully transform it into a format the assistive technology can digest.
In such wise a web facing technology to describe content is a crucial part, but even if you had it, the irony is the accessibility APIs couldn’t handle it anyways, because they weren’t designed to do so.
Let’s summarize this two piece puzzle. The first piece is that the web author needs a tech vocabulary to describe content meaning, and the second one, platforms should have a delivery mechanism to convey these descriptions to the assistive technologies.
So how would a technology that cracks this puzzle, look like?
Let’s think aloud. Say, you have a cool web app or you are provider of some unique content, and for sure it is special to fit into standard HTML. Then, of course you are able to explain it to your friends, so they understand the whole thing — sure, how they could possibly use your app otherwise? Then, you put the wording into the accessibility concepts same as above, which also means breaking it down into blocks in a way they can be processed by software.
The whole point in blocks building is that web authors need deep control over them — and this is exactly what today’s web is missing. Certainly, if authors create content, then their expressive possibilities to explain the content should not be restricted by technologies.
Let’s imagine that web authors get a true flexible tool that allows them to juggle content blocks the way they want, when the author is in charge to define new roles, states, properties and to connect the blocks to each other by any relation you can imagine. Then, all of this is piped to the assistive technologies via platform APIs (yep, it’s probably the sole requirement to APIs to being able to transfer this kind of data). And voilà, it’s all we need!
The content provider (a web author) knows the meaning of the content. The assistive technologies know how to present the content to the user, and the browser knows how to deliver it to the assistive technology.
In this scenario the browser serves as a bridge connecting the web author and the assistive technologies. The browser doesn’t necessarily have to understand the content semantics that flows through it. The browser acts as an agent that makes the author and the assistive technology to communicate directly.
Sounds amazing? Yes! Sounds fanciful? No, but the browsers and APIs vendors should work hard to make it happen.
I believe the web needs a new flexible and extensible technology to give web authors control over content they create. And it will change the web for good!
