[theme-reviewers] Accessibility Auditing of themes - next steps

Chip Bennett chip at chipbennett.net
Thu Mar 28 19:09:47 UTC 2013

We'll see how long inline responses remain legible. :)

> 0. General thoughts
> This is somewhat true, but in many cases it's really true of both --
> in general, the intent is that every issue is purely dealt with on the
> theme end, and not user content. Core functionality shouldn't
> generally be affected, but will require the occasional filter due to
> inaccessible defaults. I can provide examples, however.

Agreed, but we need to be as explicit as possible where the line between
core and Theme lies with respect to guideline conformance.

In general, a Theme should not fail a guideline for something that is
default core output.

> > 1. Images
> I'm entirely happy with mandating that all decorative images are
> output with CSS. Absolutely. There is no valid reason in my opinion
> for a theme to have decorative images in the HTML.

I'll propose this as part of the upcoming WordPress 3.6-release guidelines

> > How does this requirement impact custom header images? Do we need a
> default
> > alt attribute text for custom header images?

What about custom header images, specifically? That's the one instance
where a Theme would potentially output a non-decorative image in the

> > The alt-text decision tree would then apply only to user content, and
> thus
> > be outside the review scope
> Not quite - if we would still be allowing images in HTML, just not
> purely decorational images, then the theme developer still must
> consider the appropriate alt attribute for those images.

Let's assume that the above guideline about images and CSS will apply.

> > 2. Media auto-playing
> If a theme incorporates an audio player or video player as part of the
> theme, this would be part of the theme guidelines; otherwise, user
> content. However, we should be covered for that case.

Most of the time, an audio player is going to be considered as Plugin
territory. Nevertheless, the below guideline should suffice in all
circumstances, I think.

> > Regarding sliders: it appears that Themes will be required NOT to
> auto-start
> > sliders, or to provide a user-configurable setting for slider auto-play
> > versus manual, defaulting to manual?
> Yes, that's accurate.

I'll propose this as part of the upcoming WordPress 3.6-release guidelines

> > 3. Headings
> We certainly do not need to specify which heading to use -- that would
> be inappropriate, because the appropriate heading is very much a
> decision for the designer.
> The specific areas that really need headings are widgets and content
> areas (e.g., must use a heading to start posts or pages).

So, posts need post titles wrapped in HTML heading tags, and Widgets need
titles wrapped in HTML heading tags, and that would cover this guideline?

> I'm not sure more than that is required -- we're indicating
> "reasonable" because this is an area where the most important thing is
> the presence of headings; the specific choice of which heading to use
> is significantly less important. Nice, but less important.

Agreed. Let's focus on the template/content sub-sections potentially
defined by the Theme. I think posts and Widgets is a good definition.

> >
> > 4. Link text
> >
> > Since the default core output for the "read more" link is... "read more",
> > and since this element is not defined by the Theme, we need to define an
> > appropriate read-more link filter to meet this guideline.
> >
> > We need to define all the core-defined links that would fall under this
> > guideline.
> >
> I can do that. This is all in my plug-in WP Accessibility
> (http://wordpress.org/extend/plugins/wp-accessibility/) and I can pull
> the examples from there. Should examples be posted directly in the
> Theme Review, or should we provide an example code page?

We need a good place to put code examples. That's a work in progress. Most
importantly, we need a guideline for *what* content should be filtered in
place of "read more" (etc.)

> 5. Keyboard Navigation
> The navigation menu itself is, unstyled, fully accessible. The excess
> title attributes are a problem, but that's a core issue, and not
> appropriate to deal with for theme developers. It's the styling and
> use of the menu which are accessibility issues, and these are
> definitely theme issues. Usually, it relates to the use of display:
> none() to hide sub menus in drop downs and the method used to make
> those menus visible.

Given the prevalence of CSS dropdown menus using display:none / :hover
display:inline, this will be an important area to define explicitly,
regarding what is unacceptable, and what is necessary to conform to the

> 6. Contrasts
As far as what would be tested for contrast -- everything. The entire
> front-end of the site, in all areas.

This is where I'm struggling: how do we define this explicitly, and how do
we teach reviewers how to evaluate this?

> There are several web-based contrast analyzers. I can recommend one in
> the document -
> https://addons.mozilla.org/en-us/firefox/addon/juicy-studio-accessibility-too/
> is a very useful tool for this.

I'll have to try one of the tools to understand what we're working with. Do
these tools scan a URL, and return an evaluation of contrast, in a way that
communicates what needs to be addressed?

> That's a good point. We were more going from the concept of the
> impossibility of checking all color settings and the undue burden
> associated with that, but it is reasonable to provide a specific
> accessibility-focused color scheme as an option.

> I would be happy with stating that the review would encompass the
> default theme settings or a clearly-labeled accessible color scheme.

Sounds good. I assume that the idea is to encourage/facilitate adoption by
both new and existing Themes, but I don't see a lot of Themes making major
changes to the default color scheme.

> 7. Skip Links
> I assume you mean that we should detail what a conforming skiplink set
> up would be? I can do that.


> 8. Forms
> >
> > Since forms are core-defined content, what specific
> > wp_list_comments()/comment_form() parameters and filters are required to
> > conform to this guideline?
> Like the wp nav menus, this mostly has to do with what people choose
> to do *outside* the default -- styling and behavior. If they choose to
> implement an AJAX driven comment form, then they need to make sure
> that the response from that form is announced to screen readers. If
> they use the defaults, they're fine.

That gets more difficult, then. How do we define the changes from default
core output that would fail the guidelines?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20130328/806d17e4/attachment-0001.htm>

More information about the theme-reviewers mailing list