Note: these guidelines are draft only
The Theme Accessibility Audit provides an optional theme review for themes submitted to the wordpress.org Theme Repository. Submitted themes (or theme updates) that contain the tag
accessibility-ready will undergo an independent, accessibility review after they have been approved for inclusion in the Theme Repository.
Themes that pass this level of review successfully will be allowed to use the
accessibility-ready tag. Authors of themes that fail will be asked to re-submit their themes without the
accessibility-ready tag or make requested changes in order to meet the requirements.
Theme developers are encouraged to exceed these requirements; they are the minimum requirements for the
Themes that fail the accessibility review can still be approved for addition to the Theme Repository.
All decorative images MUST be included using CSS. Where theme authors add images to template markup, authors MUSTincorporate an appropriately used
alt attribute or the means to provide one. During the audit, a simple
alt text decision tree is used to check whether images are using the alt attribute appropriately.
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.
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, visual, 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.
Links MUST avoid repetitive non-contextual text strings such as ‘read more…’ and should also also make sense when taken out of context. Bare urls must NOT be used as links. Context-specific text MAY be positioned off-screen.
The core-defined ‘read more’ links fall under this guideline. You can use filters to replace these links. The post title should generally be used in addition to the normal directive text.
Theme authors MUST provide visual keyboard focus highlighting in navigation menus and for form fields, submit buttons and text links. Navigation by keyboard should also be intuitive and effective.
A common issue in navigation menus is with drop down menus that use a display:none/display:inline hide/reveal paradigm.
display:none removes the concealed object from screen reader’s reading, and should not be used.
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.
Unless a clearly labelled accessible color scheme is available within the theme, the default settings will be the only color scheme checked. If a theme offers multiple color schemes, only one scheme is required to pass these guidelines.
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 offscreen 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.
Comment forms MUST have appropriate field labels and all content within form tags MUST be explicitly associated to a form control. Post-submission responses MUST be perceivable.
Forms that include a single input (such as a standard search form) may, optionally, position the input label offscreen. Themes that incorporate non-standard forms (e.g. a contact form) will be audited using the same criteria.
If you are replacing the default WordPress forms, you MUST not:
- Incorporate form controls that do not have explicitly associated
- Create feedback mechanisms (such as via AJAX) that do not expose their responses to screen readers. Look at techniques with ARIA for further information.
Inclusion of any of the following is NOT allowed:
tabindexattribute, excepting negative or zero
tabindexin specific circumstances (assessed on a case-by-case basis).
- The inclusion of the
- Spawning new windows or tabs without warning the user.