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

[Chip Bennett]

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

The reason I ask about the custom header image is because, by definition,
the Theme won't have any way to know what the image content is. If an empty
alt tag is appropriate and acceptable, that might be the best approach.

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

Perfect. That's where I'm headed: objective, explicit guidelines and
recommendations. There will be a potentially steep learning curve for
developers and reviewers, so we want to lessen the slope of that curve as
much as feasible.

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

Yes, please. I anticipate that trying to move away from display:none for
dropdown menus will be a considerable paradigm shift for a lot of
developers.


> >> > 6. Contrasts
>
> 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 anticipate that this will be the area of greatest need for education.


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


That's always true, and as I often say: we do not want the Guidelines to
emulate the Code of Federal Regulations. :) The trick will be finding the
right balance between subjectivity and onerous specificity.


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

These are good examples.


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


Absolutely. The more examples/test cases we can define, the easier it will
be for everyone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20130328/98eed77c/attachment.htm>