Page Builder and accessibility
Even if you're not required to make your website accessible, it's a good idea to follow at least high-level accessibility principles. Why?
- Your site will be more readable
For example, the site has appropriately sized print.
- Your site will be more searchable
For example, there are text alternatives for content graphics.
- Your site will reach a larger audience
Your site becomes more accessible for the estimated 20% of people with disabilities, but it also becomes easier to use in general, because the basic principles of accessibility hold true for everyone.
- Your site's SEO will benefit.
For example, Google's Mobile-Friendly Test, which judges your site on criteria that contribute to Google Search rankings, will fail for some of the same reasons, such as the text being too small and horizontal scrolling required because the viewport wasn't set.
- If you're an agency, it's a benefit to say you test for basic accessibility, even when you can't guarantee that the site is fully accessible, for all of the reasons above.
WCAG 2.0 accessibility standard
The current standard for web content accessibility is the Web Content Accessibility Guidelines, or WCAG 2.0, maintained by the World Wide Web Consortium (W3C). The WCAG 2.0 specification is based on four principles:
Users must be able to perceive the information with at least one of their senses.
The interface cannot require interaction that a user cannot perform.
Users must be able to understand the information as well as the operation of the user interface.
Content must be interpreted reliably by a wide variety of user agents, including assistive technologies.
Each of these principles has both guidelines, which define goals to achieve the principles, and success criteria, which are measurable outcomes. In addition, the WCAG 2.0 specification assigns one of three levels of conformance to each of their success criteria: A (lowest), AA, and AAA (highest). Here's a page that lists the guidelines, success criteria, and conformance level for each:
Make your sites accessible
Full accessibility is rarely achieved, and meeting accessibility criteria is an ongoing effort, requiring new testing with each website revision and each authoring tool release. For this reason, meeting accessibility requirements at any level makes creating and maintaining a website significantly more costly.
On the other hand, checking a site for basic conformance, and learning how to meet basic accessibility conformance when you construct a site, are best practices, for all the reasons laid out above.
Most of the basic accessibility guidelines are met by standard practices you follow when you design the page, such as the following:
- Ensure there is good contrast between text and background.
- Make link text contextual. Rather than this language:
To view our brochure click here.
View our brochure.
Screen readers read the link text, and "click here" gives people no context as to what they're clicking or why they should do it.
- Make sure you have descriptions for non-text media that contain content (i.e., are not just decorative). This means filling in the Alt field for images in your media library that convey content, or making sure your image is described in the text preceding or following the image, or linking to an external text file that describes the image.
- Ensure you have at least one <h1> tag, and use heading tags in order: <h1>, <h2>, <h3> and so on, so the structure of your page is obvious to search bots and screen readers. Note that the use of the section tag in HTML 5 has blurred the requirement of sequential headings a bit.
- Check the HTML rendering of icons and form fields. For anything interactive without an
altattribute, or text inside, or a label, such as an icon's <I> tag, you can add hidden text specifically targeted for screen readers. Page Builder has met accessibility requirements for form fields and icons, but check the HTML output of any plugins you use.
It's also a best practice to start testing your site early and throughout the design/development process, rather than wait until you have what you think is a perfect site, only to find out that there are a number of basic accessibility issues that should have been addressed at the design stage, such as color contrast.
Whether you want to make your own site more accessible or do it for a client at their request, decide in advance what level of the standard you will meet. Agreeing on a particular WCAG 2.0 conformance level is a good way for you and the client to reach a very specific agreement, since each conformance level is associated with a set of measurable outcomes. Another way is to agree on a certain testing tool. For example, you might agree to address all issues listed on the Known Problems tab of the AChecker web accessibility checking tool.
ATAG 2.0 accessibility standard
The W3C also has a specification for Authoring Tool Accessibility Guidelines, ATAG 2.0, which are guidelines for two aspects of web authoring tools:
- Making the tool accessible when using it for authoring
- Helping authors create accessible sites
WordPress has its own accessibility team, which monitors and reports accessibility of the admin UI. Some of the Page Builder authoring user interface (UI) accessibility comes from and is limited by WordPress accessibility.
Page Builder accessibility improvements
Page Builder modules are accessible at a basic level on both the authoring side and on the HTML rendering side.
Thanks to the help of John Russell, Page Builder has improved accessibility for advanced modules.
Improvements to authoring environment
The following modules have improved keyboard navigation.
- Accordion module
- Tabs module
- Menu module
Changes to HTML output
Here are some examples of how the modules implement ARIA design practices to improve accessibility for assistive devices such as screen readers.
- Content Slider, Posts Carousel, Posts Slider modules: There are additional ARIA
roleattributes to clarify the Previous and Next arrow controls.
- Contact Form and Subscribe form modules: The input tag for each field has an added
idattribute that connects the input to the label for that field. This meets the requirement that form fields have the proper labels associated with them.
- Icon and Icon Group modules: The link has added ARIA attributes that relate the link to the icon and any accompanying text.