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

[Chip Bennett]

Okay, I'm taking a good, hard look at the draft accessibility guidelines,
thinking about how a Theme developer would account for/incorporate those
guidelines (from the perspective of my own Theme, Oenology). Here are my
initial questions/thoughts:

0. General thoughts

I'm noticing that there are many things that are going to be a matter of
user content, versus Theme design. It will be important to ensure that the
eventual guidelines carefully differentiate between the two.

Similarly, there are some things that are going to be a matter of core
functionality, versus Theme design. It will be important to ensure that the
eventual guidelines carefully differentiate between the two, and where
necessary, provide best-practice implementation (including filtering output
for accessibility issues) of core functionality.


1. Images

I think we could cover this one by stating that all decorative images are
required to be added via CSS. Are there any valid reasons for Themes to
output decorative images directly in the HTML markup?

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

The alt-text decision tree would then apply only to user content, and thus
be outside the review scope


2. Media auto-playing

In general, this will be a user-content issue, 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?


3. Headings

Let's get into specifics here. In particular: headings for sub-sections
defined by the template. I'm thinking about dynamic sidebars and Widget
titles. Do we simply need to say that Widgets need to use an HTML heading
tag for titles, or do we need to specify *what* heading tag to use?


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.

Almost every other link is defined by the user.


5. Keyboard Navigation

Navigation menus are defined by core. Does the default wp_nav_menu() output
meet this guideline? If not, then we need to define an appropriate set of
wp_nav_menu() parameters, or appropriate filters, to meet this guideline.


6. Contrasts

What all contrasts must conform to this guideline? We need to define the
contexts in which this guideline will be tested (body content, post
content, sidebar/widget content, footer content, etc.).

This needs to be something that can be automated, e.g. through Theme Check
or some other tool, whether as a Plugin, or a web-based contrast analyzer
(such as the W3C validator: input URL, output conformance results).

Also: for Themes that have multiple color schemes, why must only the
default color scheme be tested for contrast? My original intent was to add
specific "Accessibility" color schemes, but according to the draft
guideline, those color schemes would not be tested. I'm not sure that this
guideline would encourage adoption of accessibility guidelines for existing
Themes.


7. Skip Links

How, specifically, will Themes conform to this guideline?


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?


9. Not Allowed

Should be self-explanatory, and should be easily incorporated into
Theme-Check.


This is a good start. We need to work on making the requirements as
objective and specific as possible, so that they are consistently
implemented and understood by both developers and reviewers.

Thanks,

Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20130328/98826484/attachment-0001.htm>