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

[Joe Dolson]

So, back on the Theme Accessibility Audit bandwagon.

For review, the previously established steps:

=======
Review: Chip's steps to implementation:
1) Clearly defined requirements, ideally listed somewhere in the Codex
2) Updated Tag Filter
3) Identify accessibility guidelines that can be evaluated
programmatically via Theme-Check where possible
4) Identify accessibility guidelines that can be incorporated into the
Theme Unit Test Data where possible
5) Identify accessibility guidelines that can only be verified by a live person
6) Set up Theme-Trac workflow to shunt Themes using the Accessibility
tags into a separate queue
7) Volunteers to review Themes in the Accessibility queue in Theme-Trac

After a lot of labor, I wrote a set of Accessibility related classes
to be added to the theme-check plug-in, which can be downloaded here:

http://dev.joedolson.com/theme-check.zip

And can be discussed here:

http://make.wordpress.org/accessibility/2013/02/13/progress-report-theme-review-guidelines-for-accessibility/

Ultimately, there isn't a lot that can be handled within Theme Check.
Ultimately, most of accessibility is very UI dependent, so the scan
needs to be a front-end scan to be really helpful. I'm currently
working on a plug-in to integrate front-end checks via the QUAIL
jQuery library, so that will be a huge aid to front-end developers; it
shouldn't take much longer before I can get that into the repository
and have it available. For now, nothing to see here, move along
please...

The accessibility guidelines that can only be verified by a live
person are fairly standard; and, ultimately, amount to almost
everything -- so those would be referenced by the Theme Audit
Guidelines (here:
http://make.wordpress.org/accessibility/theme-accessibility-audit-draft-proposal/).
I'll make sure that those items that require a human check are labeled
as such.

Now, the work that requires somebody to actually commit some code...

Step 6: First, somebody needs to add the 'accessibility-ready' tag and
queue shunt to the theme review process. Honestly, I have no idea who
can and should do that - anybody?

Step 7: Handling the A11y volunteers to do these reviews. I've got
about six people willing to work on this, and am *happy* to take the
lead on getting this organized, once there's a system in place.

I have a concept in my head for how I feel the overall process should work:

1) The theme review (normal process, exactly as it is now) comes
first. No theme should be checked for accessibility unless it's
actually approvable for the theme repository already.
2) Once a theme review is complete, and the theme is approvable, if it
uses the 'accessibility-ready' tag, it will be shunted to a queue for
accessibility review.
3) Once that audit is complete with any required updates, the original
theme reviewer should get a final check (?) (in case a new problem is
introduced during accessibility updates), then the normal process can
continue.

This, to me, seems to minimize the alteration to existing work flow
and also ensures that the A11y volunteers aren't wasting time
reviewing themes that may never be approved anyway.

I'm hoping to move this forward relatively quickly, if possible - I
know about a half-dozen people currently working on building
accessible WordPress themes intended for the directory. They're mostly
accessibility specialists teamed up with WordPress developers, so this
could be a great test of the audit process.

Best,
Joe Dolson

On Wed, Nov 14, 2012 at 2:34 PM, Joe Dolson <design at joedolson.com> wrote:
> True - but I think a combination of the presence of any other form
> element with the absence of any label elements would be easy enough,
> and would be sufficiently accurate.
>
> Best,
> Joe
>
> On Tue, Nov 13, 2012 at 7:10 AM, esmi at quirm dot net <esmi at quirm.net> wrote:
>> on 12/11/2012 16:08 Joe Dolson said the following:
>>
>>> A couple additional (and hopefully very rare circumstances) could be
>>> screened programmatically -- a complete lack of <label> elements or
>>> <h*> heading elements would be an automatic fail, as well. We may not
>>> be able to verify that the elements are used correctly automatically,
>>> but if they were absent, that would be a definite violation.
>>
>>
>> Not sure about checking for label elements. As far as I recall, there is no
>> mandatory requirement for a theme to include it's own searchform.php or
>> comment.php files. So I'd imagine it's quite feasible for a theme to be
>> submitted without any label elements. Also a niche theme might be aimed at
>> page-only, no comment, sites. so, again - no need for a custom comment form.
>>
>> That said, the core comment form needs a good overhaul in terms of
>> accessibility, so I'm not sure how we'd handle any theme that simply pulled
>> the core form - especially since the fixes are pretty easy at the theme
>> level. Ideally, such a theme would not warrant the accessibility-ready tag.
>>
>>
>> Mel
>> --
>> http://quirm.net
>> http://blackwidows.co.uk
>> _______________________________________________
>> 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



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

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