Table of Contents
- Organizing Content Logically
- Adding Color
- Creating Links
- Adding Media
- Adding Dynamic Content
- Tool List
Organizing Content Logically
https://www.w3.org/WAI/tutorials/page-structure/headings/ opens a new window
The link provides a more detailed explanation of how to organize your content under the appropriate heading. Their purpose is meant to organize content on your page – doing so correctly makes sure Assistive Technology (AT), in most cases a screen reader, to correctly organize the content for the impaired reader.
https://www.w3.org/TR/wai-aria-practices/examples/landmarks/main.html opens a new window
This one provides more information on how landmarks work within a page. As your site has the appropriate landmarks in place for the different regions of the page you should not have to apply any new roles unless it is outside of those regions.
Color Contrast Rule
WCAG 2.0 level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. WCAG 2.1 requires a contrast ratio of at least 3:1 for graphics and user interface components (such as form input borders). WCAG Level AAA requires a contrast ratio of at least 7:1 for normal text and 4.5:1 for large text.
Large text is defined as 14 point (typically 18.66px) and bold or larger, or 18 point (typically 24px) or larger.
ADA Compliance requires Level AA although if you can make AAA all the better.
More information here: https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html opens a new window
The idea is to choose color palettes that allow the above contrast values take place. When applying text to a white background – works with darker colors – and vice versus if applying text to black or very dark backgrounds. Avoid certain colors for text if possible as they tend to be more difficult to contrast against. Examples of these would be Oranges, Yellows, Golds, and Pastel colors.
Links which direct the user to other pages within the same space do not require any special markup beyond being clear. Using words like “click here” or “read more” or other less descriptive text need to either be prefaced or appended with more descriptive details or have an aria-label and title (yes both) that describes the purpose of the link.
WCAG 2.0 has 2 additional requirements for body text links that are not underlined by default:
- The link text must have a 3:1 contrast ratio from the surrounding non-link text.
- The link must present a “non-color designator” (typically the introduction of the underline) on both mouse hover and keyboard focus.
More information on WCAG and Links: https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html opens a new window
With regards to accessibility, the W3C recommends against opening links in a new tab.
Gez Lemon wrote “Opening Links in a New Window opens a new window” in 2004 and summarizes with the following:
The best practice for opening external links is to open them in the same window, allowing the visitor to make a choice whether or not they want the link to open in the same window, a new window, or even a new tab. Deciding on their behalf is considered rude, and has usability implications.
WebAIM opens a new window gives some context on how they affect users:
The accessibility issue is that some users can get confused with the new windows or tabs. Newer screen readers alert the user when a link opens a new window, though only after the user clicks on the link. Older screen readers do not alert the user at all. Sighted users can see the new window open, but users with cognitive disabilities may have difficulty interpreting what just happened. Then when the try to click on the Back button in the browser, nothing happens, because there is no previous link to go back to in a new window or tab.
Now that all the disclaimers are out of the way – sometimes we want to include external links for specific purposes. When we do we need to add a couple of indicators that they are indeed external links. One indicator is for users whom do not use Assistive Technology and one for those that do – we need to include both to be truly compliant. An example of this is a visual indicator such as: symbol with a title=”New Window Opens when clicked” and aria-hidden=false attributes added. The other would be using hidden text from visual but not from screen reader: [span class=”screen-reader-only”]New Window Opens when clicked[/span] where the screen-reader-only class is correctly marked up in styles. Bootstrap styles use the class: sr-only for the same thing.
https://www.w3.org/WAI/tutorials/images/ opens a new window
See above link on different types of images and their purposes. In essence, if an image is meant to impart information to the reader then it needs an appropriate markup in its alternate text attribute. If appropriate for the context and a more extensive description is needed then include both an aria-label and a title attribute – these usually display the same exact text as one is read by a screen reader and the other by a non-screen reader upon hover. If however, the image is purely decorative in nature, then it still requires an alternate text attribute to be included in the image tag markup but it is set to empty: alt=””.
Video and Audio Media made Accessible
https://www.w3.org/WAI/media/av/ opens a new window
When using media of either type they require alternate means to in order to communicate the information being provided. This means for video’s offering Captioning and/or Text Transcripts and audio text transcripts. The text transcript can be a link to a file or page that interprets the visual /audio information into a written format a screen reader can read or in the case of a hearing impairment a way for them to visually access the information. Make sure if using Captioning there is sufficient color contrast between text and the background it is applied too. Video tags are generally landmarked role=presentation.
Adding Dynamic Content
WordPress and WordPress Developers love their short codes. These are simple codes used in pages to call specific functions from the WordPress site. If the developer of these short codes follows proper Accessibility Guidelines – no issues – but if it does not and it is on your site it has the potential to cause a failure in ADA Compliance.
Recommend testing with automated tools any of these additions to the site first before publishing and if there are issues – contact the developer of the product with the issues needing to be addressed. The more people do this the quicker these developers get on board with ADA Compliance.
The same goes for Site Builders – many themes these days offer short cuts for users to develop the look and feel of their site with advanced theme/plugin combinations. In fact, many offer “Pro” versions for this specific purpose – however – very few consider ADA Compliance at this time. Even those that are – still require experience on your part not to use inappropriate color combinations, font sizes, or headings for the content. Use caution when using these and when it is obvious something is not following compliance – contact the developer (especially if you paid extra for it) to fix any ADA issues with the product.
A little more advance item would be creating your own code blocks within WordPress. If you do so, follow all of the above practices and test with appropriate tools for compliance. To be really sure before publishing something custom within your site – have an expert test it for you.
Forms can be a real challenge – especially if you are using one of the many form plugins available to WordPress users these days. Even the paid plugins that let you build custom forms are still prone to common ADA errors for the sake of visibly pleasing forms. One of the most common issues is missing labels for form controls or inaccessible to keyboard alone navigation within the form.
There are ways to set styles so that a label can be included that is only “seen” by assistive technology without impacting the visual esthetics of the form itself. In addition, making sure the form controls are properly marked up allows for tabbing through the controls.
The most common issue on keyboard navigation is dropdowns (selects) not opening when the user hits the spacebar once it has “focus” or allowing select upon hitting “enter” on the desired dropdown selection, or “esc” to exit the dropdown without selecting anything.
In addition, form controls such as radio buttons or checkboxes can inadvertently be skipped during keyboard navigation if they are not marked up correctly. Consider placing the attribute, tabindex=”0″ , on radio and checkbox form controls to allow them to receive focus in the proper order (setting to 0 allows the page itself to order them with the rest of the focusable elements on the page – avoid using tabindex values greater than 0 as this in itself becomes a violation of WCAG 2.1).
And finally make sure it is receiving the correct landmarking and is unique on the page (if you have more than one form on the page this becomes an issue and a unique ARIA added attribute will be required). See above under landmarks for more details on form landmarks.
NVDA Screen Reader opens a new window and Colour Contrast Analyser (CCA) opens a new window
Both of these tools are desktop based and open source (free). One allows you to test how content is read by a screen reader to those with site impairments. Use this to sample sections of your new content (especially complex sections) for readability. The other is easy to use tool that allows you to test colors for appropriate contrast and whether they meet WCAG guidelines.
Recommend installing Google Chrome/Mozilla Firefox extensions WAVE opens a new window (by Webaim) and HeadingsMap opens a new window (by Rumoroso) for new content verification. Both of these tools allow you to thoroughly test new content and with WAVE give you recommendations on how to fix and why it is important.
Be sure to check out our other articles including: “ADA Audit – Why does a Website need it?” and “Easy Guide to Website Accessibility and ADA Compliance.”