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

Wed Mar 6 20:47:52 UTC 2013

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20130306/c8277dc1/attachment.htm>