What's the Problem in a Nutshell?
The reason why most organizations fail at accessibility is because they don't focus on UX. That may not seem startling until you realize exactly what I'm saying. You'll find plenty of people who will tell you that UX should be a part of good accessible design-- and those same people will then give you a random laundry list of best practices for what UX designers should do to facilitate accessibility. I'm saying something quite a bit different; instead, I'm saying that UX needs to be the primary driver if you really want to achieve web accessibility.
Why do we say this? Because we've worked with hundreds, if not thousands, of organizations over the last 15 years working in web accessibility consulting. And when we give accessibility audits or testing results to customers, they invariably focus on fixing the code. For a short time, everything seems fine but, after six months to a year, it's almost as if they never had an assessment in the first place. It's not because new or updated designs from their UX designers stripped out accessibility-- it's just that they didn't specifically include it. At the opposite end of the spectrum, we've worked with enterprise organizations that have incorporated accessibility in design and their sites are fine-- and they just seem to always stay that way.
The obviousness of the problem-- and its solution-- is heightened by our conversations with both developers and UX engineers. On the one hand, we hear constantly from developers "just tell us what to do". That can mean either "tell us how to code" (which most of us assume it means) but it can also means "tell us what to code" (which is more important). After all, developers are also a very resourceful bunch. If they're told to design something and how to test if they've met it, they're quite good at researching the right solution to get it done. On the other hand, when we've talked to UX designers, many take a hands off approach to accessibility and make statements ranging from "accessibility is for developers" to "accessibility just follows from basic UI design". But nothing could be more fundamental to the term "user experience" than including all users-- including users with disabilities-- and so it's fundamentally on UX designers to convey what needs to be done to developers in order to make designs useful for their users with disabilities. So, if UX engineers made sure to annotate their designs completely for accessibility and developers know how to verify that their code met those designs, the problem is solved. But, again, that means that solving the problem needs to start with UX.
What About Better Training?
I used to think that the solution for web accessibility was better training. Then, it seemed like every major web accessibility consultant created their own "university" or "academy" where developers could learn the latest tricks for achieving accessibility. Most of these programs have expanded and also include training specific to UX, graphics, and testing. And yet, web accessibility is still a mess. Now, I'm not saying that we shouldn't train web development teams. I absolutely believe that we should train developers-- and I'll give you example of this later in this blog. The real answer, however, is clearer requirements-- and more specifically, clearer requirements for UX accessibility.
So why should UX drive this effort? First, as I've mentioned, developers are quite talented at finding their own answers. I've often had to look up coding strategies myself-- and anyone with access to Google can easily find the exact code snippets that they'll need to incorporate accessibility. So this means that they'll likely code it right if given the right requirements. Second, developers are often not the right people to be doing it in the first instance. Take alt text as a simple example. How is the developer supposed to have any idea what the page's author intended as the purpose of placing an image on the page? We can teach developers all about alt, aria-label, aria-labelledby, and aria-desribedby (and their relative order according to the Accessible Name and Description Computation specification by the W3C)-- but that provides zero assurance that the right alt text is going to be provided. But the third and most important reason UX should drive accessibility that most developers just want to code in the quickest way possible to meet the requirements of the specified designs-- so if those designs don't specifically include requirements around accessibility, there is a very high probability that accessibility will not be incorporated. So, again, we can train developers forever, but if accessibility isn't required in the designs, it likely won't be in the final product.
Practical Example: Regions and Headers
I can preach on and on about my feelings about this but a practical example would demonstrate what I mean a lot better. In the following example, we have a wireframe in Figma. This wireframe is almost identical to a wireframe that one of our customers was actually using. In this wireframe, we have several brands represented in the upper left. These are separate tabs that bring up parallel web sites for associated brands. In the upper-right, we have a currency selector, an account button, and a shopping cart button (which also displays the number of items in the shopping cart). Below this, we get into one of the brands (here identified as "Brand X") with the logo, navigation menu, and product search. Below that is the main section of the page with a seasonal announcement region at the top and a carousel of "great deals on popular items" below it. The rest of the web page continues beyond this but isn't included in this image.
If the designer just handed this design to the developer, there's maybe a 50% chance that the developer would divide the web page into appropriate regions. Also, the developer will likely pay more attention to trying to make the page headers to visually look like the headers in the image instead of focusing on a logical header order. That could mean jumping directly from an H1 element to an H3, which would obviously be bad for accessibility.
Just like a contractor creates buildings according to an architect's blueprints, so should a developer create web designs according to the UX wireframes, prototypes and mock-ups. And, if those design incorporate accessibility, they can also guide testers in making making sure that the web developers creations meet the original designs. Thus, if a UX designer were really focused on accessibility, they would be required to specify this in their designs.
So, in the screenshot below, we've identified the header structure clearly with H1 and H2 annotations. Now, even if the developer thinks that the page's existing H3 headers (and not H2 headers) visually match the wireframes, they would have to restyle their H2 headers to meet the header numbering identified in the design. Also, all of the different regions (here, banner, navigation, main, and search) are clearly identified. Thus, the only way that a developer can achieve this design is to use the appropriate HTML 5 regions and ARIA landmarks.
The natural counterpart to having clear requirements in design is having clear test procedures that developers and testers can use to make sure that they got it right. But we've already covered clear testing processes in a previous blog. And, as discussed in that blog post, it's easy enough to use the free Accessibility Bookmarklets. For instance, QA and testing teams could just run the Landmarks bookmarklet and instantly compare how the landmarks were coded by developers against the original designs.
In the screenshot above, you can see that the QA team's layout of regions (as shown by the Landmarks bookmarklet) exactly matches what the UX designers specified. Awesome!
The final ingredient, of course, is development strategies. Again using our simple example above, we just need to make sure that developers understand that the wireframe needs to leverage the appropriate HTML 5 regions and ARIA landmarks to make the design work. In this case, it would be the following code.
<header role="banner">
<!-- banner contents here -->
<nav role="navigation">
<!-- brand selector here -->
</nav>
<h1>
<!-- logo here -->
</h1>
<nav role="navigation">
<!-- menu here -->
</nav>
<form role="search">
<!-- contents of search go here -->
</form>
</header>
<main role="main">
<!-- contents of main go here -->
<h2>Great Deals on Popular Items</h2>
</main>Frankly, the need for development strategies is the least important element because there are a gazillion examples of exactly what needs to be done just one Google search away. Instead, having (1) clear designs describing where accessibility is needed and (2) clear test processes to verify it was done correctly are more important. Nevertheless, having instant access to the right coding strategy makes life easier for developers and speeds things up.
Giving Credit and Next Steps
This idea of annotating wireframes for accessibility is something that we've been doing for the last 13 years-- even before we focused on wireframe designs for accessibility at our presentation at CSUN in 2010. I'd love to say we originated the idea but in reality we were just one of a number of early voices in the choir. Since then, it's become quite popular as a topic and companies like Microsoft and Adobe have contributed towards a fairly standardized effort that goes by various names, such as "Accessibility Bluelines" or Microsoft's "Fluent Accessibility Notation". Just searching the web, Jack Nicolai from Adobe and Jen Smith from Microsoft have both given excellent presentations around this topic.
In our web accessibility efforts, though, we've noticed a few hiccups that make it hard for organizations to just roll out good web accessibility design principles in this manner. First, it needs a framework to ensure that proper annotations are a requirement and not a pie in the sky best practice. As we've said earlier, if it's not imposed as a requirement on UX designers, there is no assurance it will get done. And, it seems, only the largest IT companies and most sophisticated design shops have this kind of framework. Second, it needs to be backed up with development strategies and, even more importantly, easy test processes. Third, if WCAG compliance is really important, it needs to cover everything in WCAG-- and not just obvious examples like header structure and regions.
It's here that WebAlign is making a difference for our customers. We give you the framework that you need and level of instruction to make it simple. We've described just one example of how it works, but WebAlign goes far beyond this and our frameworks covers all of WCAG. Plus, we're constantly updating it to make it more complete and more responsive to our customer needs. And, lastly, it's based on a logical and affordable pricing model. If you're ready to try WebAlign, contact us today!
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
Thanks for the attribution and the fantastic work here, Ken. All brilliantly said. I’ve had this article bookmarked for ages…all waiting for time to read it and it was well worth it.