Who does it benefit? Keyboard-dependent navigators or users of alternative input devices who are sighted.
Theme authors must provide visual keyboard focus highlighting in navigation menus and for form fields, submit buttons and text links. All controls and links must be reachable using the keyboard.
Fails: Dropdown navigation menus are hidden using display:none; and brought into view on :hover
Passes: Dropdown navigation menus are hidden using position: absolute; and brought into view on :hover and :focus, and are navigable using the tab key
Better: Dropdown navigation menus are hidden using position: absolute; and brought into view on :hover, :focus, and are navigable using either the tab key or by using the keyboard arrow keys.
How to test:
Using tab key, tab forward through site. Test to make sure that links, buttons, form fields, and dropdown menus are available using the tab key.
Make sure you can see visually which link is focused. Focus should either incorporate a visual change that is not based on color (background change, underline, shape) or a color change where the difference between the two colors meets color contrast guidelines.
Make sure that focus doesn’t move in unexpected ways around the page.
Test shift+tab to move backwards and confirm that works, as well.
Who does it benefit? Screen reader users and keyboard navigators.
Themes must include a mechanism that enables users to navigate directly to content or navigation on entering any given page. These links may be positioned off screen initially but must be available to screen reader users and must be visible on focus for sighted keyboard navigators.
A minimally conforming skip link must:
Be the first focusable element perceived by a user via screen reader or keyboard navigation.
Be visible when keyboard focus moves to the link.
Move focus to the main content area of the page when activated.
There is an outstanding bug in WebKit-based browsers that prevents focus being moved to elements that aren’t natively focusable. You can either enqueue JS to patch this bug or assign tabindex=-1 to your main content region to handle this issue.
How to test:
Verify that skip link is present.
Verify that skip link is first focusable object on the page when not logged in
Verify that skip link becomes visible when it receives focus
Verify that skip link points to the content area of the site correctly
Who does it benefit? All users, but principally screen reader users and keyboard-dependent users.
Comment forms must have appropriate field labels and all content within form tags need to be explicitly associated to a form control. Post-submission responses (errors or confirmations) must be perceivable. If you are using the default WordPress comment or search forms, these pass the accessibility-ready criteria.
Forms that include a single input (such as a standard search form) may, optionally, position the input label offscreen.
If you are replacing the default WordPress forms or form behavior (such as to handle responses with AJAX), you MUST:
Use form inputs that have explicitly associated <label> elements.
Create feedback mechanisms (such as via AJAX) that expose responses to screen readers. Look at techniques with ARIA for further information.
Who does it benefit? Screen reader users, SEO, voice recognition users
Theme templates should use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup must not be used for presentational purposes. Heading elements for structure may be positioned off-screen as long as this is not at the expense of providing good structure.
Specifically, sub-sections defined by your theme must use heading elements. This includes wrapping your post title in a heading when used in an article context and wrapping widget titles in headings.
These are specific criteria that are used to judge whether your hierarchy meets our requirements:
No H1 element present on the page.
All headings on the page are H1 headings.
Headings do not skip levels when descending. H1 cannot be followed by H3, etc.
Who does it benefit? Screen reader users. Landmarks provide method for screen readers to navigate to the large structural regions of a site.
Assign landmark roles to the main content areas of your site. All content on your site must be wrapped in at least one landmark role; any content not wrapped in a landmark role is ‘orphaned’, and may not be found by screen reader users.
Appropriate usage of roles:
role="banner" == header
role="main" == main content
role="complementary" = sidebars
role="contentinfo" = footer
role="search" = search form
role="navigation" = navigation menus
If a particular role appears more than once on a page, you should provide an ARIA label for that role:
It’s impossible to specify how many landmarks any page should have, but keep in mind that too many landmarks can create confusion for users who need to remember what information is in a landmark section. If you have more than 10, you may need to remove or consolidate regions.
How to test:
Verify that all content is contained inside at least one aria landmark.
Verify that aria landmarks are appropriately chosen
If a major landmark, such as navigation, is used more than once, ensure each is labeled uniquely.
Links must avoid repetitive non-contextual text strings such as ‘read more…’ and should make sense if taken out of context. Bare urls must not be used as links. Supporting text may use a screen reader class to hide text visually.
The core ‘read more’ links fall under this guideline. The post title should be used in addition to the string used for “Read more” text.
It is also an acceptable option to exclude ‘read more’ links entirely, as long as the post title is linked to the full post.
Who does it benefit? Color blind users, users with age-related eye issues, users in bright sunlight or glare.
Most themes provide methods to modify colors or change color schemes. The principle of this guideline is that if a user does not change any default colors their site will be accessible.
Theme authors must ensure that all background/foreground color contrasts for plain content text are within the level AA contrast ratio (4.5:1) specified in the Web Content Accessibility Guidelines (WCAG) 2.0 for color luminosity.
Background/foreground color contrast also applies to change of state (:focus or :hover) if there is no additional indicator of :focus or :hover, such as a text decoration change.
Decorative images must be included using CSS. Where theme authors add images to template markup or provide a method for end users to add images, theme authors MUST incorporate an appropriate alt attribute or the means for an end user to provide one.
Featured Images: The alt attribute for featured images is defined in the media manager. In any case where a featured image is displayed, the alt attribute must be included with the image.
Icons and icon fonts: if the icon is representing text (e.g., there is no visible text), the icon must include fallback text for screen readers that indicates what the icon means. If the icon is supplementing text (e.g., it appears with text that indicates function or purpose), then the icon should not include fallback text, and should be hidden from screen readers using aria-hidden.
How to test:
Look at featured image presentation, make sure alt attributes are included with image
Look at any icon fonts or decorative images in use on the site. Ensure that icon fonts have fallback text alternatives when needed (e.g. when icon font is a link on itself), or are hidden if not (e.g., ornamental icons connected to other links)
Who does it benefit? Screen reader users and users with cognitive impairments.
Media resources must NOT auto start or change without user action as a default configuration. This includes resources such as audio, video, or image/content sliders and carousels.
In general, media resources of this nature are likely to fall under the plugin territory guidelines, and will not be allowed in your theme. If you have a conforming usage, however, these rules will apply.
How to test:
If a special feature (such as a content slider) is enabled by default, ensure that the feature is accessible using all of the guidelines and applying them to that feature. (This is very rare)
It is not required to use screen reader text in your theme to meet accessibility-ready guidelines. Any text which is commonly hidden visually and provided for screen readers can legitimately be made visible for all users.
If you are making text available only for screen reader users, there are two valid ways to do this. You can either use text hidden in a valid screen-reader-text class or use aria-label or aria-labelledby attributes to provide an accessible name for what you’re labeling.
If you use .screen-reader-text, then you must use one of the recommended techniques for hiding that text visually.