Accessibility Decay: Why Your Paid Accessibility Remediation Only Lasts So Long

If you are new to the topic of web accessibility, there is a lot to absorb about what it means to make your website accessible. Some common accessibility issues are inherent to the way your site was coded while others have more to do with the content that you populate into your site. In search engine optimization (SEO), the practice of trying to make your site rank higher in search engine results, there is a common distinction between technical SEO and content SEO. Essentially, there are a set of technical best practices that every site should incorporate in order to score well for Google and other search engines. However, those steps are necessary but insufficient. If you want to rank highly for a specific search term, you have to write your content and add metadata in the right way. (If you’re interested in learning more about these SEO concepts, this post from Custom Fit Online is an oldie but goodie.) I think this same framework is a useful way to think about web accessibility.

Technical Accessibility

The simplest way to explain technical accessibility is that it contains the list of all accessibility standards that are encoded into your site. As a result, it is rare that you will be able to address most of these checklist items without the assistance of a developer or coder. The flipside of that proposition is that once these items are implemented or fixed, it is unlikely that you will personally be able to break them.

One illustrative example of technical accessibility is the requirement that all sites be fully navigable using a keyboard. This means that users who cannot see the screen or those that do not have the physical dexterity in their hands to operate a mouse cursor should be able to access any element on your site using the tab and enter keys on their keyboard. In order to comply with this requirement, all site elements need to be coded in such a way that they are discoverable (not skipped) by the keyboard when tabbing through the site. They also need to be ordered logically so that the user does not end up jumping around the site.

Of course, it is quite possible that some of these accessibility features may break as you design and code new features or pages into your site. We have found that if you don’t explicitly list accessibility as a requirement, it is common for developers to accidentally introduce new technical accessibility issues when making changes to your site (especially when the developer or agency making the changes are not the same folks you hired to originally build or remediate your site).

Content Accessibility

In contrast, content accessibility relates primarily to the content that you add to your site (or edit) on an ongoing basis. While there are things that a developer can do to make it easier for you to keep things accessible (or harder to screw things up), for the most part, this is on you. This means that keeping the content on your site accessible requires an ongoing commitment and some knowledge of best practices.

The most typical example of content accessibility is the need to provide text-based alternatives for any non-text content (such as images or videos). Users that rely on screen readers to interact with your site are excluded from interacting with such content and providing alt text can describe what is on the screen.

Which is more important?

Trick question!

Both technical accessibility and content accessibility are critical. Addressing only one set of guidelines will result in a site that is completely unusable for many users with disabilities. The Web Content Accessibility Guidelines (WCAG) guidelines includes 78 checklist items; many of those items relate to both technical and content accessibility. But it is possible to roughly divide the guidelines into these separate categories. Below, I’ve included a non-comprehensive list of WCAG items categorized by type of accessibility.

Technical Accessibility in WCAG

• Encoding regions of the page (like the header, footer, and menus) so that screen readers can situate the user in context
• Users should be able to bypass sections that repeat across the site (like the header)
• The language of the page should be encoded so that screen readers know how to pronounce words (especially words that are spelled the same but pronounced differently in other languages)
• The site should generally be visible in various sizes and orientations (landscape or portrait)
• All forms should include field labels that can be read programmatically
• Any audio that plays for longer than 3 seconds has a site-based mechanism for pausing or muting
• Any blinking, scrolling or auto-updating information can be paused, stopped or hidden by the user
• Text can be resized up to 200% without loss of content or functionality
• Text is of sufficiently high contrast to be easily readable
• Sites should not have any flashing content that can cause seizures

Content Accessibility in WCAG

• Adding alternative text for images
• Providing a transcript for prerecorded audio or video
• Providing audio descriptions for video
• Closed captioning on video
• Using structural markup (like headings) to indicate the outline of a page and relative importance of different headings
• Images with text should not be used instead of text
• Users should be able to tell where a link is going from context (i.e. you should avoid link text like “click here”)

Accessibility Guidelines That Are Both Technical AND Content Related

While the breakdown between technical and content accessibility is useful, it isn’t possible to assign all accessibility rules to one or the other category exclusively. There are some things that you can code generally but still must pay attention to on individual pages. One such example would be rules for minimum color contrast. The idea here is that if two colors are side-by-side (for example, the page background color and text color on top of it), they must be sufficiently distinguishable so that someone with low vision can easily read or perceive the content on the page. You will want to make sure that your site design or theme follows this rule generally, but also want to be sure that any new content that you produce is also compliant.

Aspirational Accessibility: Shooting for AAA

The WCAG guidelines have 3 levels, which are ordered in level of importance. In general, Level A represents a minimal level of accessibility; if these standards are not met, it would be just about impossible for users reliant on assistive technology to use your site. Level AA is a higher level of accessibility. In general, achieving AA level accessibility should allow assistive technology to use the site under most circumstances. It is generally accepted that that the ADA requires that sites meet the WCAG 2.0 Level AA guidelines.

Each of the WCAG guidelines is assigned to one of these levels. In some cases, there may be separate guidelines covering a specific issue (such as minimum color contrast rules) at different levels, which means that even if you have already made your site accessible, it is possible to raise the bar.

The Level AAA guidelines are heavily (though not exclusively) related to content and many of them are easily taken into account as you build out your site:

• No use of “images of text”
• Use Section Headings to organize your content
• Buttons and links should be large enough that users with fine motor control issues are able to easily click on them (e.g. 44 x 44 pixels)
• Add definitions for unusual words or phrases (including jargon)
• Define all abbreviations
• Text should not be simple enough to be understandable by a user at a 9th grade reading level

Covering all of your bases

Paying close attention to technical and content accessibility is necessary to ensure that your site is ADA compliant. While taking care to code your site accessibly (or remediate it if you didn’t do this at first) can get you part of the way, any coding changes to your site can introduce new issues and set you back. Combine that with the need to closely monitor content accessibility and it’s clear that you can’t just “set it and forget it”.

While we agree that investing upfront in coding your site the right way is the best approach to accessibility, if that hasn’t happened, you will need to review your site for accessibility violations and remediate them based on severity so that you can bring your website back into compliance with the WCAG guidelines and the ADA.

If you’d like to learn about how we can help you review your site, please get in touch today. We’d love to chat!