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

[Chip Bennett]

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
revisions

>
> > 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
template.

>
> > 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
revisions.

>
> > 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
guideline.

> 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.
>

Exactly.

> 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>