This document is a work in progress and is subject to a review by the WordPress Theme Review team.
The Theme Accessibility Audit is designed to offer 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 a further, independent, accessibility review after they have been approved for inclusion in the Theme Repository.
Themes that pass this second review successfully will be allowed to retain the accessibility-ready tag. Authors of themes that fail will be asked to re-submit their themes without the accessibility-ready tag.
(Need to confirm the exact process with the Theme Review Team with regard to the most practical way to handle successful/failing themes.)
Themes that fail the accessibility review will still be approved for addition to the Theme Repository.
Audit Criteria
The accessibility audit will be carried out by a small team of expert users and developers using the following criteria:
Images
Wherever possible, decorative images should be applied using CSS. Where it is necessary to add images to the template markup, all images MUST incorporate an appropriately populated alt attribute. During the audit, a simple alt text decision tree will be used to determine whether images are using the alt attribute appropriately.
Headings
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.
Link Text
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.
Keyboard Navigation
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,
Contrasts
Theme authors MUST ensure that all background/foreground color contrasts are within the level AA contrast ratio (4.5:1) specified in the Web Content Accessibility Guidelines (WCAG) 2.0 for color luminosity. In themes where a number of color schemes are offered, only the default scheme will be assessed.
Reference: WCAG 2.0 Color Criteria
Skip Links
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.
Forms
Comment forms MUST have appropriate field labels and 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.
Not Allowed
Inclusion of any of the following is NOT allowed:
- The inclusion of the
tabindexattribute with the exception of negativetabindexin specific circumstances (to be assessed on a case-by-case basis). - The inclusion of the
accesskeyattribute. - Spawning new windows or tabs without warning the user.
(Note: these could added be flagged up by the Theme Check plugin.)
AccessibleJoe 12:01 pm on October 18, 2012 Permalink |
I applaud this effort. Standardizing a process to evaluate theme accessibility is essential. It will help theme developers by informing their process, and it will help site owners to know that a theme has passed an optional compliance check.
toscho 7:30 am on October 24, 2012 Permalink |
To address a very common issue with forms: the
placeholdermust not be used as alabelreplacement, and it must not repeat thelabeltext.Aaron Jorbin 4:28 pm on October 24, 2012 Permalink |
This is a great start. A couple of comments:
For Contrast, are we also going to test against various color deficiencies? If so, which ones?
Also for Contrast, I think we should specify the AA level requirements of WCAG. The way it’s worded right now leaves it a bit up in the air.
esmi 4:37 pm on October 24, 2012 Permalink |
Initially, I’d say no. We don’t want to bog theme devs down with too much at first. Nor would we want to restrict their choice of colour schemes. This, of course, does not stop them from checking for various types of colour blindness themselves.
And we are deliberately NOT referencing WCAG conformance levels as that would require a complete site for auditing. There is a limit of what even the most accessible of themes can do and we do not want to lull site owners into thinking that they can just use one of the themes and then forget all about accessibility issues in their content.
Joe Dolson 11:43 pm on October 24, 2012 Permalink |
@toscho We certainly agree with that, but I think it’s covered in the statement that forms must have an appropriate label: a placeholder is *not* a label, and will not be accepted as a substitute for one.
@Aaron Technically, the color contrast scale is designed to provide sufficient contrast for various color deficiencies, because the algorithm measures relative luminosity rather than just color difference. Doing checks for color-driven language seems like something that is unlikely to crop up (although we should keep a watch out, just in case).
@esmi I think that Aaron meant that we should specifically indicate what level of color contrast we’re checking for: e.g, the AA 4.5:1 ratio as opposed to the AAA 7:1 ratio, which I think is reasonable. We don’t want people to think we’re limiting their color choices that significantly.
esmi 10:46 am on October 25, 2012 Permalink |
Ah! That makes sense. I see you’ve amended the text already.
@Aaron: Is that better?
PhilippeVay 8:13 pm on October 30, 2012 Permalink |
Great news!
My 2 cents:
Headings
The HeadingsMap extension for Firefox is a great tool to visualize if a hierarchy of headings in a page is correct or no.
Link text
Will empty links be forbidden?
Keyboard navigation
In addition to outlined links, there shouldn’t have keyboard trap either.
The test is pretty straightforward: beginning from the first link (or the URL field) and keeping the Tab key pressed “for a while”, does the focus return to the beginning of the page or does it stay trapped into a part of the page?
Related WCAG 2.0 Technique and Failure are G21 and F10.
Contrasts
WCAG 2.0 only asks for at least a 3:1 contrast ratio in the case of “large texts”, also at the AA level. I don’t know many designs where both normal and large texts have contrast ratio above 4.5:1 (that is, where large texts pass the AAA level).
Skip links
What about adding a third link to navigate directly to the Search field? The id of its input is the same in most themes (#s) so it’s pretty straightforward.
Also, no need for a link to navigation if the beginning of navigation is two links forward (for example, a link on logo going back to home and right after the navigation).
esmi 2:38 pm on November 1, 2012 Permalink |
One that actually reflects the document’s structure as opposed to using heading markup for purely presentational or seo reasons.
Ideally, yes but we wouldn’t fail an otherwise accessible theme for skipping the odd heading tag – primarily because, in Real Life, user agents can (and do) handle this kind of situation without too many problems.
Not too sure about this one. I’d have to defer to my AT using colleagues. The issue here, IMO, is going to be whether how a screen reader handles (like JAWS) handles this kind of page when it is used to create a heading list. What we’re really trying to do is ensure that screen reader users can still construct a meaningful mental model of the page;s structure.
If they’re completely empty, I’d say yes. Unless you can come up with a good argument for using them in the first place…?
Good point. I’ll added a line to the Keyboard Navigation section to cover this.
Re contrasts and skip links, we’d need to look at these on a case-by-case basis. WCAG’s definition of “large text” is difficult to apply when a design uses relative font units.
toscho 3:19 pm on November 1, 2012 Permalink |
Empty links can happen when someone sets a link around an image with an empty
altattribute. Not easy to spot sometimes.esmi 3:53 pm on November 1, 2012 Permalink |
Ah! No – that would definitely not be allowed.
toscho 4:41 pm on November 1, 2012 Permalink |
wp_get_attachment_image()(used for thumbnails) can return emptyaltattributes in some cases. An accessible theme must filter'wp_get_attachment_image_attributes'and fix that.esmi 5:14 pm on November 1, 2012 Permalink
We would simply be picking up on any theme-controlled images that lacked an alt attribute or linked images with a null attribute. It’s not really our place to define how developers address any such issues – although, of course, we hope to be able to offer some best practice recommendations down the line. So I don’t think it would be appropriate for the accessibility review to start demanding mandatory filters for core functions. Especially for something like
wp_get_attachment_image()which is not used by all themes.Joe Dolson 4:39 pm on November 1, 2012 Permalink |
“With HTML5 doctype, is it OK to rely on the outlining algorithm and have themes using only h1 as headings (in a correct manner, per HTML5)?”
I’d say no, on this — currently, screen readers have very poor support for the HTML5 outlining algorithm, and this will probably continue to be true for quite a while. Someday, but for now, this does not provide effective accessibility.
esmi 5:16 pm on November 1, 2012 Permalink |
screen readers have very poor support for the HTML5 outlining algorithm, and this will probably continue to be true for quite a while
That was my gut instinct too. I’d imagine this will continue to be the case until HTML5 becomes a formal (as opposed to draft) specification.
Web Axe 4:55 pm on November 12, 2012 Permalink |
Good stuff everyone! I suggest adding a point for sufficient text size. Details are highly debatable, I’ll just refer to the Smashing Mag 16px article: http://bit.ly/nhg38i
esmi 5:11 pm on November 12, 2012 Permalink |
I’d agree that it’s something we might want to look out for but I don’t think it can be mandated. Many developers don’t use pixel-based text sizes for this very reason.
Web Axe 2:10 am on November 13, 2012 Permalink |
Mentioning sufficient text size is better than not at all. I’d prefer a suggested size, but isn’t necessary. It doesn’t matter the unit of measurement, it’s the point that counts; besides, the size can always be easily converted.
Samuel Joehl 5:39 pm on November 12, 2012 Permalink |
For comment and other forms where field constraint is indicated (such as required fields or formatting requirements) the constraint must be programmatically associated with the form field so that it is announced as part of the label when the field receives focus; otherwise users may miss this information and be confused, for example, which fields are required and which are optional.
esmi 7:18 pm on November 12, 2012 Permalink |
That’s already covered in the Form section.