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

[Joe Dolson]

I'm responding inline to give my views on these - hope inline works well.

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

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.

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

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.

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

The default alt attribute text should be empty, for unknown content;
but otherwise, the important thing is that is should be possible for
users to define alt attributes for the images. I'm not sure how much
this is a theme issue -- if the image content is provided by the user,
then that aspect of it is user content. If the mechanism for defining
an alt attribute is provided by WP core, then that's a core issue
(under ATAG guidelines)

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

>
> 2. Media auto-playing
>
> In general, this will be a user-content issue, I think.
>

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.

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

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

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

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.

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

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

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.

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

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.

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

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.

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

>
> 7. Skip Links
>
> How, specifically, will Themes conform to this guideline?
>

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.

>
> 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
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>



-- 
==================

Did I help you with one of my plug-ins? Donations keep support
possible! http://www.joedolson.com/donate.php

==================

Joseph Dolson
Accessibility consultant and WordPress developer
http://www.joedolson.com
http://profiles.wordpress.org/joedolson