Recently, I was lucky enough to catch a workshop by Brian Sinclair entitled 'Accessibility: The Basics and Beyond.' The workshop was part of the DinosaurJS conference in Denver CO.
As part of the accessibility group at Mediacurrent, I was excited to see the issue being addressed at a javascript conference.
Since the launch of Drupal 8, front-end developers have had to pay a little more attention to either including or not excluding the accessibility features of Drupal. As decoupling the front end from Drupal is becoming more common and we use frameworks like Vue or React to provide the user interface, we need to make sure that we understand what we need to do accessibility wise to make sure that our sites and applications are available to all. If we are writing the markup, we need to make sure that we are aware of the HTML accessibility requirements without relying on the work of Drupal’s accessibility team.
What a good time to get a refresher on basic accessibility - why we do this, and how to use the docs.
So one of the main takeaways from the ‘Why we do this?’ section was that improved accessibility means an improved user experience for everyone. When we are focused on how things work for people who are accessing content in different ways, we are more conscious of how our site works. This mindset has the benefit of improving the experience for all users. In other words, ‘solve for one, extend to many.’
The ’Tools’ section of the presentation was extremely insightful. This centered around the WCAG 2.0 guidelines. Despite having been on the accessibility team for a year and reading this site many times I had not noticed how the guidelines were grouped. The sections are an acronym, POUR. Which stands for:
Perceivable - can everyone consume this content?
Operable - can you use it, can everyone use it, tab, enter etc.
Understandable - Does the content even make sense? Can someone use the site without explanation?
Robust - Can it be used in a broad variety of environments?
This is likely obvious, however, I had not made the connection and this really changed my perception of the guidelines. By understanding what each section was targeting, and relating each section to each other it really helps approach projects and issues with greater confidence.
When discussing the levels for WCAG 2.0, which range from A through AAA, AA is the target that most accessibility teams aim for. However knowing your audience is as important as adhering to standards. In Brian’s example he pointed out if your website or app is only available for Apple users, then there is little benefit to supporting internet explorer. The same is true for accessibility. You might not need to provide an extremely robust screen reader support if all users are using the built-in Apple voiceover. Sometimes it is not useful to say ‘we have to meet every AAA standard, or even AA’ if the site content doesn’t suit that need.
Another big takeaway from the tools sections was that the software tools we use when testing our sites to make sure that we are not overlooking any areas are not 100% foolproof. Things like aXe and Wave will catch some of the errors and oversights but are no real guarantee that you have hit everything. It is also worth noting that some items that are flagged may not be either desired or required. For example, sometimes providing alt tags for images that serve no useful information to a screen reader is better than bombarding the screen reader with information. The main takeaway for me was that we always need to be thinking about what we are presenting and how it is being viewed. If we can justify the decisions that we made then we will be in a better place for future iterations.
Overall I found this presentation to be very useful. I try to attend all of the accessibility talks at the conferences I go to because I think it is important to support the work but also it is good to make sure that I am on the right track for current approaches. As we work on projects where we can’t fall back on provided HTML structure, it is important that we understand how to get the information we need and access the tools available to us.