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

[Joe Dolson]

On Thu, Mar 28, 2013 at 2:09 PM, Chip Bennett <chip at chipbennett.net> wrote:
> We'll see how long inline responses remain legible. :)

Indeed...

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

Absolutely agree; but in general, the core output is almost never
going to be the problem, and in the few cases where it could be, I
would not choose to fail the theme because of it - that just means
that the issue needs to be raised in core. I think there are just a
few issues where we want to require filtering, and I'll make certain
those get documented clearly.

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

Then the custom header image needs to have an appropriate alt
attribute. What that alt attribute is, however, would be determined by
the content of the image -- if it includes text, that text must be in
the alt attribute. I think that if a theme provides an image, then
that image needs to have an alt attribute. An empty alt attribute is
entirely acceptable, assuming that the image doesn't require alternate
content.

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

Sounds good.

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

Agreed.

>
> 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 think that would cover the guideline. There are other possible uses
of headings that are beneficial, but I think those generally fit into
"going above and beyond" or are user-content.


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

The key thing is that the read more text should be unique to the link
it points to. Since all contexts that WP uses this text in pertain to
posts, the standard content would be to include the post title as
unique text. I'll make this clear in the guidelines.

>> > 5. Keyboard Navigation
>>
>
> 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.
>

The important thing comes out of testing: keyboard testing is trivial,
since it just involves navigating the menu using a keyboard. For
screen readers, it's just a matter of *not* using display: none. But
this can be documented explicitly.

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

Scanning for contrast is actually an incredibly difficult problem, due
to the CSS cascade. The algorithms for determining what colors are
actually involved in a given contrast pair is very difficult. So, the
tools do scan the URL and return an evaluation of contrast, flagging
potential issues. However, a visual confirmation of the issues is
necessary, because not all flagged contrast errors will be real: some
will be due to the algorithm in use detecting the wrong
background/foreground element pair.

This is going to take some learning, ultimately. Contrast is very easy
to evaluate, once you get comfortable with the tools and the concept
-- but it does take judgement to test.

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

That's a definite goal, and well worth accommodating.

>> > 8. Forms
>>
>> 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?
>

I'm not sure we can specifically delineate all possibilities. Any
change that results in form responses not being exposed to assistive
technology would be a failure. Similarly, any customization that
results in the removal of labels would be a failure. Some of the ways
the form could fail are covered in other guidelines - using tabindex
would be a failure, for example.

We can't say that all changes in core output would be failures,
because it can also be improved -- but the numbers of ways that
failures can be generated is fairly broad.

The methods for testing are fairly straightforward, however. I can
list those out, if it would help.


> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>