Cross posted from medium.
I see it happen on a regular basis, a client insists that their site is “fully accessible” or “fully WCAG 2.0 AA Compliant,” and it isn’t even close, and I don’t mean “they missed a spot,” or that there is some narrow area that I would have personally handled differently. I am referring to giant, obvious, even basic accessibility issues that still exist on the supposedly compliant site. Usually, the culprit is a web-related services company who added “accessibility remediation” to their service offerings without fully understanding what that meant or gaining the necessary expertise.
Let me be clear, any improvement in the accessibility of a site is good, even if the site is far from “fully accessible.” We do not want the perfect to be the enemy of the good. There are, however, a great many companies offering “complete compliance”, “certified compliance”, “certified ADA compliance,” and “certified WCAG 2.0 AA compliance,” that have in reality, chosen to pay attention to only a fraction of the standards that they are claiming to attain.
To state it in another way, if a company is certifying a website as “fully WCAG 2.0 AA compliant” then they should know every WCAG 2.0 AA success criteria inside and out. They should understand the best practices that are recommended by the W3c and by the web accessibility industry. They should be well aware of common failures for every success criteria and how to spot them. They should know the strength and weaknesses of automated testing and when manual testing and QA are needed (which will be something like 70-80% of the work that they do). They should know what it means to get as close as reasonably possible to that conformance level as a site can get. And they should absolutely be aware that while a high level of conformance is possible, perfect conformance is not.
Here are some of the major accessibility failures I see regularly on allegedly “WCAG 2.0 AA certified” websites.
Text Images
No, you may not just use text images wherever you feel like it. Text images are not accessible. They cannot be resized, or restyled for users that have vision or cognitive issues. That is why they are effectively prohibited where they can be recreated via css and actual text. There are a narrow range of exceptions to that rule for items like logos, and depictions of font families. I see this all the time on these supposedly remediated sites — dozens to hundreds of ads and banners that use images of text. Often the developers of these sites do not even attempt to include all of the text from the image in the alternative text attribute, which violates another success criteria.
Contrast
If you do not understand the color contrast requirements, then you are missing one of the most basic accessibility requirements. The problem is that there is a little bit of variation in the contrast requirements based upon the size of the text. Some “accessibility remediation” providers seem to have decided that a 3:1 ratio is all that is needed for all circumstances. Sorry, no. For fonts that are smaller than 24px and not bold the criteria is 4.5:1. If your font is bold that change happens at 18.66px — smaller than that and bold still needs the 4.5:1 ratio.
Pause moving content
Does your content move, rotate, animate, or update, for more than 5 seconds? Then you need a pause button. That means that unless it stops moving entirely and never moves again by the 5 second point, then you should have some sort of pause button that stops the movement. Your auto-rotating banner is entirely non-compliant without this. Your animated flash ad in the sidebar is non-compliant without a pause button. Where is it?
Forms need labels
Yes, there are some exceptions to this rule, but those exceptions are there for circumstances where a label would not provide a benefit, or might make the interface more confusing. You can’t just toss your form input labels because your design team thinks a form looks “cleaner” without them. This is such a basic requirement, that it amazes me how often I see sites that completely neglect this, or use some other technique to try and work around it. Placeholder text is not a replacement for labels or instructions, because placeholder text disappears when you type into its associated input.
Focus States
Have you ever tried to navigate your computer with a mouse after the cursor has disappeared. You can’t do anything, because you can’t figure out where you are on the screen. Focus states are the equivalent of the mouse cursor for keyboard users. If you have disabled focus states or overridden the defaults with something effectively invisible, then you have a site that is not navigable with a keyboard, and hence not accessible. Visible focus states are an explicit WCAG 2.0 AA requirement.
Hidden panels that are not properly hidden
So you are casually using your keyboard to navigate through a website when suddenly your focus state disappears, and then it reappears 40–50 tabs clicks later. It probably just disappeared into a hidden menu that was not fully hidden from the DOM. This happens when developers hide an element by using off screen positioning or some other similar technique rather than “display: none” or “visibility: hidden.” The result is that you just failed the keyboard operability requirement, the visible focus states requirement, and the focus order requirement. It’s like a three-for-one failure, and it really does create a terrible experience for keyboard users.
Look Ma, I beat the automated accessibility checker!
Automated accessibility testing tools are very important, however, they can give you false positive results, false negative results, and they really only cover a small fraction of the accessibility issues that need to be fixed. The vast majority of the issues (75–80%) can only be found via manual testing. But that doesn’t stop less-than-well-trained remediation companies from simply trying to beat a specific accessibility tool, rather than developing a full remediation plan. In the process, they often create problems worse than the ones they are trying to fix.
I have seen sites that put “display: none” on their form labels. This accomplishes nothing. It does not provide readable labels or useful instructions to any of your users. But it does fool some accessibility testing tools.
On another occasion, I saw a site in which the “accessibility remediation company” realized that that css icon fonts (Font Awesome in this case) needed some sort of text inside of a link. Screen readers cannot read css icon fonts, and so when they are used for a link, the developer needs to provide some sort of text to the assistive technology users. The developers at this firm solved the problem by using a span element with “display: none” on it, inside the link. The span had the proper text of the link — the names of the associated social media websites in this case. Unfortunately, assistive technology does not read elements that have “display none” on them. So what did this accomplish? It passed an automated accessibility tool, while not actually providing readable text or a functional link to assistive technology users.
Assistive Tech users are not the only users you are trying to reach
Don’t “screen-reader-only” your skip link. Seriously, don’t do it. Think of all the sighted people with mobility issues that really do not want to tab through all of your navigation. Think of them, please. And while you are at it, labeling inputs in a form actually helps everyone understand what your form is for. Please don’t “screen-reader-only” your labels on anything that is not a super simple, very small (like single input) form. I understand that sometimes you are trying to squeeze a little search box into a small area of a header somewhere, it is already obvious that it is a search box, and that a label could be redundant. But did you really just “screen-reader-only” all of the labels on your “contact us” form? Seriously, don’t do that. For those not familiar with the concept of “screen-reader-only,” there are multiple techniques for visibly hiding an element while making it still readable to screen readers. Sometimes, these techniques are both necessary and appropriate, but like any useful techniques they can be misused and misapplied. Remember to consider how those without assistive technology might be using your site. Users with mobility impairments, but not vision impairments are often forgotten in the push to make a site “screen reader friendly.”
Don’t Forget HTML validation
It’s actually really important that your HTML be parseable. Browsers are very forgiving when it comes to developers using poorly formed code, deprecated code, and even misusing their HTML. If you don’t ever try out the validator, you will never figure out that those <style></style> tags are really only supposed to go in the head of your document, not the body. You might never figure out that your CMS is injecting duplicate ID’s into your page. You might never notice that half the attributes you are using on your tables were deprecated a long time ago. Not every piece of software that attempts to read your page will be as forgiving as a browser, and all of your careful efforts to make your site accessible could be in vain, if it turns out to be non-parseable.
Headings have an order
That’s what the numbers are for. H1, H2, H3… They should go in order. They are not there to satisfy the styling plans of your designer. They should be used in a logical way. Your H1 should be closely related to the title of the page, or be a clone the title itself. Each subheading that is not nested inside of another heading will probably be an h2 at this point, subheadings nested inside of h2’s should be h3’s, etc. There are multiple requirements that relate to this, but the most relevant is likely that the structure of your page should be programmatically determinable. If you are using fake headings like bold font in the place of an actual h tag, or mis-ordering your headings, your page structure will not be understandable to assistive tech users.
Use roles and aria attributes correctly
Semantic HTML elements have implicit roles, you should know what those are. Both aria attributes and roles are meant to be used in specific ways, and have rules for how they are used. Some aria attributes are not allowed on specific html elements. Some areas of your page are considered landmarks, and should have appropriate roles associated with them. Sometimes, remediation firms completely muck this up, and even, on occasion, make up their own roles or aria attributes. Seriously, you can’t just make up your own “aria-stuff”.
The bigger picture
There are so many other issues that are necessary to address to make a website WCAG 2.0 AA compliant — i.e “fully accessible.” The things I listed above are actually the very basic requirements. And when a remediation company has misunderstood, or even completely failed at the basics, then I already presume that they are missing the much more complex issues.
If they can’t figure out contrast or form label requirements, I am going to presume they do not know how to support 200% zoom, or that they have not adequately screen reader tested their sites on IOS devices. They probably never noticed how very inaccessible their mobile menus or accordions are. I am also going to presume that they do not have a clue about how screen readers deal with form input validation, or if their forms are even usable with assistive technology.
Imagine, for example, if every single form on a site was completely unusable to non-sighted users, in spite of the fact that the site was “certified accessible,” because it was using an old inaccessible version of captcha. I have witnessed this on multiple sites, and it is tragic. The owner of the site sincerely believes that they are serving all of their users with a fully accessible site, while entirely failing in one of the most crucial areas.
As developers, we have been misusing and abusing our HTML for years. We have developed and propagated css techniques that fail to consider how both third party software, and assistive technology users will interact with our sites. We have almost entirely neglected the concept of keyboard navigation while designing our desktop sites around the interactive presumptions of mouse and trackpad use. And we have embedded widgets and tools into our sites that block some groups of users entirely from using the services offered by our sites. This is why a deep understanding of website accessibility is crucial to not just those developers that specialize in it, but to all developers who work with the web.
Writing Rainbough 