Future AccName Spec planning, strategy, and functional testing using the AccName Prototype

By Bryan Garaventa

Not long ago, I published a notice about the AccName Prototype and how it can be used to test the W3C AccName algorithm.

https://www.linkedin.com/pulse/how-test-accname-algorithm-dynamically-using-bryan-garaventa/

Since then, based on various questions I received privately, it became clear to me that the purpose of the project may be unclear, as is the goal, what it is meant to do, why this matters, and why I’m doing this.

Basically, the purpose of this project is to solve a specific problem that has existed for years, which is the widespread lack of interoperability between the browsers when it comes to the AccName algorithm.

Interoperability simply means that the same code should work in the same ways in all browsers equally. This is not the same as having acceptable differences in how elements behave differently across various browsers when functionality and styling are different, but instead, refers to the underlying algorithm that dictates how all elements are computed so that they always return equally predictable Names and Descriptions for all element structures that require them.

Since this algorithm is at the heart of all virtual technologies, it must be adopted in a way that supports equally accessible processing across all devices and platforms. This means, that they all have to use the same algorithm to achieve this. Or to put it another way, if you always add the same numbers in a particular order, it is reasonable to expect that you will always get the same result.

This is where the AccName specification comes in, which is meant to document the steps for building this algorithm into software platforms.

The Problem

When the AccName 1.0 spec was first written, it was done without a working prototype to test the processing impacts as it was being developed, which caused many important concepts and blind spots to be only vaguely referred to or not included at all, prompting browsers to individually fill in the gaps themselves however they saw fit at the time. Over time, this led to major and often contradictory differences between the mainstream browsers and how they computed accessible names and descriptions, even though they were all based on the original AccName algorithm.

When this became apparent, AccName 1.1 was created to address these plus new technological developments, and this too was largely done without a working AccName prototype to test the concepts before they were written. As a result, more important blind spots were later discovered, including more grey areas that were not sufficiently explained to allow for widespread interoperability to be reasonably achievable.

The Solution

To address this, the AccName Prototype was created, which is not only meant to follow the AccName specification, but also to directly mirror the concepts and processing additions that are agreed to by the ARIA Working Group while developing AccName 1.2. The working code also acts as a testing engine to validate these processes before they become written spec.

This allows us to validate the recursive impact of the working algorithm using many different coding structures to test against. It allows the public to test their own markup to get a better understanding about how this algorithm works and is meant to work going forward. It allows browser providers to test their own internal algorithms against the working prototype to identify their own blind spots and divergent processes that were not spotted previously for quality assurance. It allows all involved to get on the same page and file bugs where necessary to make this work even better when discrepancies or missing functionality is discovered so it can be addressed in the future.

Unexpected Consequences

In recent years, new accessibility tools have been created to help developers and testers better understand accessibility within web technologies, and many of them now include versions of the AccName algorithm that is based on the 1.0 or 1.1 specifications.

As a result, bugs are being filed against various browsers when these tools report a violation in the AccName algorithm, and there is a good chance that the same code may yield different results depending on which accessibility tool is being used at the time, which might not actually match the intended purpose of the AccName algorithm as it has already been discussed and agreed to for AccName 1.2 going forward.

This is especially important, because browser providers are already including concepts discussed for AccName 1.2 within their internal algorithms, so if a particular tool only tests for the literal meaning of the 1.0 or 1.1 specifications and does not take anything else into account, it is very likely that false violations will be flagged and filed as bugs against browsers in the future.

The long term impact of this situation, is that it will become impossible to achieve interoperability when everybody wants the same code to do something different on all mainstream platforms.

Managing Expectations

To make this situation manageable, there needs to be a tie breaker, so that the same code can be checked against the latest developments as agreed to by the ARIA Working Group for AccName 1.2. Then, if a bug is found to exist, it can indeed be filed accurately with the relevant browser providers so they can fix it. This is where the AccName Prototype applies.

The AccName Prototype is meant to be the functional representation of what the AccName algorithm is intended to do in accordance with the AccName spec, plus ongoing developments meant to test for and address new spec additions that will be included within AccName 1.2. As such, its purpose is to always reflect the will of the ARIA Working group, including mainstream browser providers, to provide the latest and most accessible results possible going forward as these technologies evolve.

Why Me

I joined the W3C in 2014, where I assisted with the development of the Accessibility API mappings specification, originally referred to as the UAIG (User Agent Implementation Guide). After that, I assisted with the ARIA 1.1 specification. In recent years, I have moved onto the AccName specification, and last year, I was asked to become primary editor for AccName 1.2, which ties into the development of the AccName Prototype.

To illustrate the process, every week, the ARIA Working Group discusses the latest outstanding issues and proposals, and eventually we reach agreement on various topics. When this is done regarding AccName, my first task is to replicate the processes involved to see if they work reliably without breaking anything already represented within the AccName Prototype, then to come up with a way of explaining that as a textual algorithm, which is sort of the opposite of the way that AccName was developed in the past. This will allow us to identify issues long before they ever become an issue in the spec though, and I believe this strategy will work much faster for the browser providers who are already implementing these experimental changes into their algorithms going forward, plus their feedback is a critical aspect to this overall process.

Summary

Hopefully it is now clear what the AccName Prototype project is, and why it is important.

If you want to create tools that include your own versions of the AccName algorithm, please do, hands-on experience is often the best way to learn. However, before filing bugs against relevant browsers, please check the same markup within the AccName Prototype to see if you have the same test results, which will cut down on the submission of false violations.

https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html

If you want to use the AccName Prototype for any reason, you are welcome to do so. It is open source and you can reference the live algorithm directly from GitHub, or download/clone the project for your own purposes as you wish.

https://github.com/WhatSock/w3c-alternative-text-computation

All the best,

Bryan