How accessibility is similar to SEO
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.
Subscribe to our Newsletter
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 flip side of that proposition is that once these items are implemented or fixed, it is unlikely that you will personally be able to break them. Of course, it is always possible that a developer will accidentally introduce new technical accessibility issues when making changes to your site.
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 can’t physically 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.
Content accessibility
In contrast, content accessibility relates primarily to the content that you add to your site (or edit) on an ongoing basis. There are things that a developer can do to make it easier for you to keep things accessible (or harder to screw things up). But for the most part, this is on you. This means that keeping the content on your site accessible requires an ongoing commitment to keeping the site accessible 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 will result in a site that is completely unusable for many users with disabilities. The Web Content Accessibility Guidelines (WCAG) include 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
- 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”)
Overlapping requirements
We created some neat divisions above between technical and content accessibility requirements. But there are some guidelines that can fall into both categories. In these cases, both the development and content teams bear some responsibility for ensuring accessibility. Typically this means that the developer should ensure that the default styles or functions are accessible while the content creators need to avoid introducing any new issues in these areas. For example, the site’s default colors should have sufficient contrast while page builders must follow the approved styles.
Opportunities to go above and beyond for content accessibility
WCAG has 3 levels: A, AA, and AAA. The generally accepted standard for conformance is the AA level. But it is worth familiarizing yourself with the AAA guidelines and identifying areas where you can aim higher. The AAA checklist has a number of content accessibility options that can be within reach for editors and content creators. You might consider incorporating some of the following AAA content accessibility guidelines into your site:
- Include sign language interpretation for videos
- Avoid having any flashing content at all
- Include breadcrumbs on your site to make it easier for users to situate themselves
- Write link text that clearly describes the purpose (or destination) of the link
- Write simply and clearly so that your content can be easily understood
- Provide pronunciations inline when the meaning of a word would be ambiguous without knowing how to pronounce it
How to get started
As we noted above, technical accessibility can be easily maintained once achieved. But if a site was not built initially with technical accessibility in mind, it will likely need some work to get there. Access Armada can advise on the best place to start and help you implement high impact remediations out of the gate.
When it comes to content accessibility guidelines, going back to fix old posts and pages can feel daunting. But the good news is that it is never too late to start taking accessibility seriously. We recommend that you start by focusing on making all of your new content accessible. Automated scan tools like WAVE can help you find some of the low hanging fruit as you create new pages. Your team may also benefit from content accessibility training to educate team members on the importance of accessibility and how they can incorporate it into their content creation and editing processes.
