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

Wed Mar 6 21:01:40 UTC 2013

For the most part, that seems very practical. My only concern with the
'avoiding the middle man' method is that it will make it much more
difficult to find qualified accessibility reviewers; although I'm
certainly happy to provide advice and help with anybody struggling
with an accessibility audit.

It does make sense to keep the workload focused, however -- all things
considered, I'm not anticipating an immediate flood of accessible
themes.

Esmi and I can take on editing the Theme Review codex.

The Accessibility checks would not be hurt by some better regex, but I
can keep working on those.

Best,
Joe

On Wed, Mar 6, 2013 at 2:47 PM, Chip Bennett <chip at chipbennett.net> wrote:
> Okay, here's how I would envision the next steps:
>
> 1. Someone from your team edit the Theme Review Codex entry, to add the
> draft Accessibility guidelines:
> http://codex.wordpress.org/Theme_Review#Accessibility
>
> 2. Otto or Pross merge the Accessibility checks into Theme-Check
>
> 3. Otto whitelist the "accessibility-ready" tag in the tag filter in Extend
>
> 4. Otto edit Theme-Trac to apply "keyword=accessibility-ready" to tickets
> for Themes with the "accessibility-ready" tag
>
> 5. Any one of the Theme Review admins create a new Accessibility Queue in
> Theme-Trac. This is done, assuming the keyword is correct:
> http://themes.trac.wordpress.org/report/9
>
> Then, we have some decisions to make regarding workflow.
>
> What you propose can probably work, but it is a significant change from our
> current workflow (tickets get shunted into a priority queue, accepted,
> resolved/closed). To do what you propose, we would need:
>
> 4. Create an "Accessibility" queue, that uses the "accessibility-ready"
> keyword, plus some other, second keyword, so that Themes can go from their
> otherwise-normal queue, get reviewed, then get shunted to the Accessibility
> queue. Then, reviewers would have to review the Theme, and instead of
> approving it, add the second keyword (e.g. "accessibility-review-needed"),
> so that it then goes into the Accessibility queue.
>
> My preference would be to avoid the middle-man, and just have the
> Accessibility reviewers simply perform full Theme reviews. That way, the
> "accessibility-ready" tagged Themes could get shunted immediately into the
> Accessibility queue, reviewed once, and then resolved
> (approved/not-approved). But, that would really depend on workload.
>
>
> On Wed, Mar 6, 2013 at 3:23 PM, Joe Dolson <design at joedolson.com> wrote:
>>
>> 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
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
>
> _______________________________________________
> 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