ADA Compliance for WordPress Websites

Wordpress

Aug 11, 2020

In this article we will see ADA Compliance for WordPress Websites

Table of Contents

In today’s digital era, creating accessible and inclusive online experiences is paramount. Websites that are not compliant with the Americans with Disabilities Act (ADA) guidelines not only exclude individuals with disabilities but also face legal risks. If you’re using WordPress as your website platform, you’re in luck!

We’ll guide you through the essential steps to ensure ADA Compliance for WordPress Websites. Let’s embark on this journey to build inclusive online spaces that cater to all users.

What is ADA Compliance for WordPress

According to the World Health Organization, 285 million people have vision impairments, and around 15 percent of the world’s population, or an estimated 1 billion people, live with disabilities.

As websites and mobile applications have grown rich and creative, they have become less accessible to these users.

Accessibility in web design means creating websites and applications that everyone can use, regardless of hardware, software, or any sensory or physical impairment.

The Americans with Disabilities Act (also known as ADA) is a comprehensive civil rights law that was enacted to protect individuals with disabilities from discrimination. Since 2010, various courts have heard parts of the DOJ’s argument. The results have been mixed.

ADA Compliant for WordPress Theme Requirements:

Followings are basic theme requirements to make ADA Compliance for WordPress Websites.

Keyboard Navigation: The site must be navigable via the keyboard, with no need for mouse interaction.
Controls: Appropriate semantic HTML elements are used for site controls, such as <button>, <input>, and <a> elements.
Skip Links enable users to bypass navigation and skip directly to content or vice versa.
Forms must use appropriate and explicit field labels.
Headings: Heading levels and content should follow a hierarchical structure without skipping levels.
ARIA Landmark Roles: All content must be wrapped in at least one landmark role.
Links in content must be underlined and links in navigational areas must be clearly distinguishable.
Repetitive Link Text should be descriptive and meaningful. Avoid “read more” and “click here.”
Contrasts: All background/foreground colors should contrast sufficiently to pass the WCAG guidelines.
Images: Themes must include alt attributes and/or the ability for the end-user to add alt text.
The media must be controllable by the end-user. Sound and video must not auto-play.
Screen Reader Text: Provide context for elements such as icons.
The following are not allowed under the accessibility-ready tag: Positive tab index attributes, the inclusion of the access key attribute, opening content in a new tab or window without warning the end-user.

ADA Coding Standards

Followings are best practices to make ADA Compliance for WordPress Websites.

1. Heading structure

The H1 is the main heading representing the page title on every core page. For subsections, use a reasonable HTML heading structure — including the use of heading elements for page subsections. Heading markup should not be used for presentational purposes.

Use H2 through H6 to give internal structure to the page.
Don’t skip heading levels.
Don’t add extra functionality inside a heading, like links or buttons.

2. Semantics for Controls

Controls with a native keyboard interaction (buttons or links) are always preferred. If there is a valid target link for the control, either an in-page reference or a link, then the control should use an <a href="{your-valid-target}">. If there isn’t, it should use a <button>.

3. Links

Use meaningful link text to describe the resource: Never “click here” or “more info”.
Avoid the title the attribute in anchor elements (<a>).
Avoid the target attribute in anchor elements.
Provide :focus and :active link highlighting.
Underline links in the content. Do not rely on color alone.
Include the document title in “Read More” links (can be hidden by the screen-reader-text CSS class).

4. HTML5 sectioning elements

Use HTML sectioning elements: <header>, <nav>, <main> (only one <main> per page), <aside>, and <footer>.
Put all parts of a webpage inside one of the above elements (leave nothing orphaned).
Add an aria-label to distinguish the same sectioning element used more than once. For example
On a search form: add the role search

5. Landmarks (for older browsers)

Older browsers (i.e. Internet Explorer 8 or less) don’t support HTML sectioning elements. If you need to support them you should use ARIA landmarks:

Identify the regions of a page with the ARIA landmark roles: banner, navigation, main, complementary, and contentinfo.
Apply these landmarks only once per page: banner, main, and contentinfo.

6. Skip Links

AT browsers need to way to quickly skip from the top of a page directly to the content. These “skip-links” are often hidden visually (via CSS) but readable by AT browsers and visible when accessed via the keyboard.

Provide a keyboard-accessible link above the page header that goes to the main content section.
Confirm the link is visible when in :focus state (test using keyboard navigation).

For example, in your header.php theme file, close to the <body> tag, you could place this code (adapted from Twenty Sixteen):

<a class="skip-link screen-reader-text" href="#content"><?php _e( 'Skip to content', 'theme_text_domain' ); ?></a>

See the Twenty Sixteen styles for the .skip-link, .skip-link:focus, and .screen-reader-text classes.

Many themes provide this feature to make ADA Compliance for WordPress Websites.

7. Images and Icons

Any image resource must include an accessible name. In some cases, the accessible name should be an empty string. An image can be represented by an actual <img> element, an icon font, or an svg element; but any graphical representation is considered an image for these purposes. Different types of elements use different types of accessible names.

For <img> elements, the accessible name should be in the alt attribute. If the img is ornamental, the alt attribute should still be included but left empty.

For icon fonts, the font icon itself should have the aria-hidden attribute, with screen-reader-text in a neighbor element. If the icon is ornamental, the font icon should still have the aria-hidden attribute, but the screen reader text should be omitted.

<a href="this.html"> <span class="dashicons dashicon-thumbs-up" aria-hidden="true"></span> <span class="screen-reader-text">Something</span> </a>

For SVG, the SVG should be inline, so that accessible information isn’t hidden from assistive technology. SVG elements should contain a <title> element with the accessible name of the image. For cross-technology support, the title element should be associated with the svg element via aria-labelledby. For maximum compatibility, all SVG elements used to represent an image should carry the role attribute with a value of ‘img’.

If the SVG element is ornamental, then the title element should be omitted and no aria-labelledby attribute should be present. The SVG element should also carry the aria-hidden attribute.

8. Audio and Video:

Avoid auto-play.
Provide controls to start, stop, and pause media.
Offer transcripts of audio, with summaries of sounds (e.g., “[laughter]” or “[explosion]“).
Offer captions for video, with summaries of sounds, settings, actions, text, and facial expressions necessary for understanding the content.
Consider offering extended audio descriptions of movies, a longer audio-only version that tells the same story and presents the same information.

9. Color Contrast:

The WordPress project aims to maintain color contrast accessibility at the WCAG AA level. This requires a minimum contrast between background and foreground colors (4.5:1; 3.1:1 for large text). These rules also apply to neighboring text, such as the color difference between linked text and adjacent unlinked text (when there is no underline or other differentiating feature).

The contrast between the background and foreground colors for text should be a minimum ratio of 4.5:1.
The contrast ratio applies to differently colored adjacent text, like link-text.
The contrast ratio applies to all states of text, including :focus and,:visited for links.
For font sizes 24 pixels or larger, or 19 pixels when bold, the color contrast ratio must be a minimum of 3:1.
Test your design palette in a color blindness simulator.
Avoid using color alone to distinguish important elements.

10. Labeling:

Existing code uses a mixture of explicitly and implicitly labeled fields, but all new code must use an explicitly associated <label> element (using for/id attributes and not wrapping the form control). Labels are not required to be visible but must use the .screen-reader-text class when hidden. Placeholders are fine but are not a substitute for labels. For all labels, clicking on the field label should cause the associated field to receive focus or, for checkboxes and radio selectors, select that choice.

Don’t introduce new title attributes to convey information. Use aria-label when you need to provide an alternate label and .screen-reader-text if you’re appending additional data.

When creating forms, use <fieldset> and <legend> to group logically related form elements inside complex forms or to group radio buttons and checkboxes under a heading.

11. Forms:

Add a <label> element to all form inputs. (Labels can be visible only to screen-readers.)
Use placeholder text, if needed, to augment but not repeat label text, and never as a substitute for a label.
Use an aria-label to provide an alternate label and screen-reader-only text to append additional data.
Do not introduce new title attributes to convey information.
Group related radio buttons, checkboxes, and connected form elements (e.g.: name, address, email) logically with an <fieldset> element and under a heading using <legend>.
View the default WordPress comment and search forms for examples of forms that pass the accessibility-ready criteria.
Avoid using a positive tabindex attribute — it hijacks the browser’s natural tab order (tabindex=-1 is allowable in certain cases).
Post-submission responses, such as errors or confirmations, must be perceivable to all types of users. Create feedback mechanisms (such as via AJAX) that expose responses to screen readers.

12. Animations:

Provide controls to pause movement or scrolling.
Restart a pause from where the user stopped it.
Allow users to finish an activity without any time limit.
Provide a text version of any visual information critical to understanding a webpage.
Avoid animations that blink more than three times per second.
Provide ways to stop or remove any potentially distracting elements

Ensuring ADA Compliance for WordPress website requires collaboration and awareness across your organization.

By prioritizing ADA compliance for WordPress website, you can demonstrate your commitment to inclusivity and create a website that is accessible to everyone, regardless of their abilities.

ADA Compliant WordPress Themes:

The followings are a list of themes to make ADA Compliance for WordPress Websites

https://wordpress.org/themes/tags/accessibility-ready/

Online Testing Tool:

The followings are a list of online testing tools to check ADA Compliance for WordPress Websites

Google Chrome Audit
https://wave.webaim.org/
https://achecks.org/achecker/
https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh
https://webaccessibility.com/
https://color.a11y.com/?wc3 (Color Contrast Accessibility Validator)
https://www.boia.org/w3c-tools-services-a11y
https://userway.org/

ADA Compliant WordPress Plugins:

The followings are the list of plugins to make ADA Compliance for WordPress Websites.

Reference Links:

In this blog post, we’ve explored the vital steps to achieve ADA compliance for WordPress websites. By understanding ADA guidelines, choosing accessible themes and plugins, optimizing content, conducting regular audits, and educating your team, you can build inclusive online spaces that cater to individuals with disabilities.

Embracing ADA compliance for WordPress websites not only helps you avoid legal risks but also demonstrates your commitment to accessibility and inclusivity. Together, let’s make the web a more accessible place for everyone.

I hope this helps you know ADA Compliance for WordPress Websites!

Blog