Navigating Gray Areas in Website Accessibility

It's no secret that the current ambiguity in accessibility laws and regulations has led to increased scrutiny of websites belonging to our clients, their peers, and many others. Our clients have a genuine desire to provide the best possible experience for all their audiences, but the path to compliance is littered with complexities.

While many accessibility performance tools and scans exist, there’s no single, sanctioned, “official” test that will give you a black and white answer or solution. On this issue, there’s actually quite a bit of gray. At Fastspot, we’ve spent a great deal of time evaluating tools and scanners to identify the most valuable resources in verifying accessibility from a human standpoint and compliance with accessibility regulations. We partner with clients to help ensure that they’re meeting the legal requirements for compliance as well as optimizing human experiences (which, interestingly, don’t always align) by providing a custom, tailored approach.

Setting a Baseline

Here at Fastspot, our accessibility tool of choice is Pa11y (pronounced Pally). Our developers install Pa11y on each of our clients’ sites and run it regularly throughout the development lifecycle of a website. Pa11y creates a report for each template, which we then share with our client. The report shows errors, warnings, and notices based on the selected WCAG preferences (WCAG 2.0 AA is the default). It’s easily scannable and gives code hints when it finds an error. We find that Pa11y is consistently useful and instructive for our developers, whereas more ‘automated’ tools can actually harm the integrity of the code.

HTML is a powerful, extremely flexible language. Writing HTML “well” is largely dependent on interpreting standards and, when completed, contributes to many aspects of a site – from SEO, to accessibility, to consistent presentation across devices. When it comes to accessibility, developers can sometimes feel like they’re robbing Peter to pay Paul. We’ve faced situations where achieving a higher “score” in an accessibility scan required us to compromise SEO best practices. That can mean making hard decisions, and in those times, it’s our job to advocate for the real impact on the user.

Every accessibility tool understands basic rules and guidelines, but each implements them in different ways. For example, accessibility guidelines require a link within regular-styled text to be decorated with an underline. However, while there are many different ways to style a link with an underline, some tools won’t recognize it unless it’s created with one particular CSS property. In contrast, Pa11y acknowledges visual cues can be achieved via alternate code approaches. If we choose to design a unique underline, Pa11y recognizes our alternative and understands that the underline still adheres to the spirit of the guideline. The needs of the user are being met, and Pa11y won’t “ding” the site because of a rigid and inaccurate standard.

Update March 2019: Fastspot now uses Axe Accessibility Testing Apps to run compliance scans. Axe is quite similar to Pa11y in terms of the the results it returns; however, we found it much friendlier for our team to use. More on our reasons behind the switch to Axe can be found in this recent post.

Understanding Accessibility Results

The Pa11y accessibility report breaks down flagged code into notices, warnings, and errors.

Notices are alerts that do not require immediate action, but indicate you should take a second look to ensure you’re following the accessibility rule. With large sites, it’s normal to have a long list of notices. This is cause for attention, but not concern. Notices are most commonly suggestions and reminders of best practices.
A warning is similar to a notice in that you don’t need to change anything, but you should double check your code is correct, as with our underlined link example above. The developer, who is knowledgeable about the guidelines that are at issue, can make a human determination about whether the standard is being met. Warnings are stronger than notices, but aren’t cut and dry violations. They require interpretation.
An error is something that must be corrected in order to pass the Pa11y test. This is the standard by which we judge compliance of all the sites we create for our clients. However, as explained below, today’s websites and the code that constructs them are far more advanced than the scanners auditing them. There’s still no substitute for human testers.

Update March 2019: Fastspot now uses Axe Accessibility Testing Apps to run compliance scans. For more information on the (very similar) reports Axe returns to that of Pa11y, please read our recent blog post.

Testing the Assisted Experience

While Pa11y is our primary tool for testing compliance, using the VoiceOver application to browse a site allows us to experience the quality of our work. VoiceOver is an application that is built into every computer. It reads the content of a website out loud and is vital to some users browsing the web. When we build our websites, we prioritize the user utilizing VoiceOver over automated scanner results. We’re satisfied when every user can engage with the content our clients create, and a passing grade from Pa11y is merely part of how we accomplish full engagement. Having a human tester go through our sites using VoiceOver is useful because it allows our team to see if content flows as well as we expected and planned.

Update March 2019: Fastspot now uses Axe Accessibility Testing Apps to run compliance scans. Read more about our use of Axe in this recent post.

Balancing Guidelines & Experience

Using accessibility attributes is a major priority in our code. ARIA labels and descriptions are used to further clarify context and are added into the structural HTML, which has a standard of its own to follow. We never want to sacrifice the integrity of our HTML. Instead, we build these attributes on top of HTML best practices.

Let’s get a little technical here: VoiceOver will read all ARIA labels, which are used in cases where a text label is not visible on the screen, and heading tags. Some automated scanners will flag an error if a heading tag is not directly inside of the section tag, forcing a developer to add an ARIA label to the section that matches the heading text. VoiceOver will then read the same thing twice. This may meet accessibility standards, but it’s not convenient or intuitive for actual users with screen readers.

In the event that a scanner makes code recommendations that would erode the VoiceOver experience, Fastspot prioritizes the better user experience rather than acquiescing to the scanner.

Responsive Design and False Positives

With the introduction of responsive design, and as browsers accept more complex code, websites have become very sophisticated. Behind the scenes, there is a lot of “showing” and “hiding” happening, meaning code often exists in an invisible state. Some of that code gives accessibility scanners fits.

A particular example of this is mobile navigation. The header you see on the desktop version of a site versus the header on the mobile version are completely different. Thus, we have to work some code “magic” to show and hide these elements. These are the same pieces of content, but they are presented at different times. Two pieces of code that work in conjunction, but never at the same time. Some tools will flag this as an error under “duplicate ARIA labels”, completely ignoring the valid “hidden” attribute. Those tools don’t properly evaluate modern code technologies like media queries, which we use to show and hide elements on the page.

In our code, we give these elements the same ARIA label of “Site Navigation,” as they are the same pieces of content. And we supply a “hidden” attribute so VoiceOver will only read one at a time.

Another common challenge that our clients run into is text over image. Text over image is always dinged by an accessibility scan as having insufficient contrast between the foreground text and background color. Theoretically, this may be true, but in reality, there are instances when contrast is clearly considered and text is extremely readable. This is a false positive. It maintains the spirit and intent of accessibility even while bending the formal rules.

When a creative approach yields a false positive on one of Fastspot’s projects, we discuss the issue and the potential pros and cons with the client and determine how to move forward. Typically, we agree to live with the false positive with a shared understanding that the spirit of accessibility has been prioritized, despite the results shown by the scanner.

In Conclusion

Ultimately, when it comes to accessibility, there are no shortcuts. There’s ample gray area and proving compliance still involves levels of subjectivity. The goals related to accessibility that are set by your key stakeholders will have an impact on the creative decisions you will want to be making, so be sure to get alignment.