<div dir="ltr">Okay, here's how I would envision the next steps:<div><br></div><div style>1. Someone from your team edit the Theme Review Codex entry, to add the draft Accessibility guidelines:</div><div style><a href="http://codex.wordpress.org/Theme_Review#Accessibility">http://codex.wordpress.org/Theme_Review#Accessibility</a><br>
</div><div style><br></div><div style>2. Otto or Pross merge the Accessibility checks into Theme-Check</div><div style><br></div><div style>3. Otto whitelist the "accessibility-ready" tag in the tag filter in Extend</div>
<div style><br></div><div style>4. Otto edit Theme-Trac to apply "keyword=accessibility-ready" to tickets for Themes with the "accessibility-ready" tag</div><div style><br></div><div style>5. Any one of the Theme Review admins create a new Accessibility Queue in Theme-Trac. This is done, assuming the keyword is correct:</div>
<div style><a href="http://themes.trac.wordpress.org/report/9">http://themes.trac.wordpress.org/report/9</a><br></div><div style><br></div><div style>Then, we have some decisions to make regarding workflow.</div><div style>
<br></div><div style>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:</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 3:23 PM, Joe Dolson <span dir="ltr"><<a href="mailto:design@joedolson.com" target="_blank">design@joedolson.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, back on the Theme Accessibility Audit bandwagon.<br>
<br>
For review, the previously established steps:<br>
<br>
=======<br>
Review: Chip's steps to implementation:<br>
1) Clearly defined requirements, ideally listed somewhere in the Codex<br>
2) Updated Tag Filter<br>
3) Identify accessibility guidelines that can be evaluated<br>
programmatically via Theme-Check where possible<br>
4) Identify accessibility guidelines that can be incorporated into the<br>
Theme Unit Test Data where possible<br>
5) Identify accessibility guidelines that can only be verified by a live person<br>
6) Set up Theme-Trac workflow to shunt Themes using the Accessibility<br>
tags into a separate queue<br>
7) Volunteers to review Themes in the Accessibility queue in Theme-Trac<br>
<br>
After a lot of labor, I wrote a set of Accessibility related classes<br>
to be added to the theme-check plug-in, which can be downloaded here:<br>
<br>
<a href="http://dev.joedolson.com/theme-check.zip" target="_blank">http://dev.joedolson.com/theme-check.zip</a><br>
<br>
And can be discussed here:<br>
<br>
<a href="http://make.wordpress.org/accessibility/2013/02/13/progress-report-theme-review-guidelines-for-accessibility/" target="_blank">http://make.wordpress.org/accessibility/2013/02/13/progress-report-theme-review-guidelines-for-accessibility/</a><br>
<br>
Ultimately, there isn't a lot that can be handled within Theme Check.<br>
Ultimately, most of accessibility is very UI dependent, so the scan<br>
needs to be a front-end scan to be really helpful. I'm currently<br>
working on a plug-in to integrate front-end checks via the QUAIL<br>
jQuery library, so that will be a huge aid to front-end developers; it<br>
shouldn't take much longer before I can get that into the repository<br>
and have it available. For now, nothing to see here, move along<br>
please...<br>
<br>
The accessibility guidelines that can only be verified by a live<br>
person are fairly standard; and, ultimately, amount to almost<br>
everything -- so those would be referenced by the Theme Audit<br>
Guidelines (here:<br>
<a href="http://make.wordpress.org/accessibility/theme-accessibility-audit-draft-proposal/" target="_blank">http://make.wordpress.org/accessibility/theme-accessibility-audit-draft-proposal/</a>).<br>
I'll make sure that those items that require a human check are labeled<br>
as such.<br>
<br>
Now, the work that requires somebody to actually commit some code...<br>
<br>
Step 6: First, somebody needs to add the 'accessibility-ready' tag and<br>
queue shunt to the theme review process. Honestly, I have no idea who<br>
can and should do that - anybody?<br>
<br>
Step 7: Handling the A11y volunteers to do these reviews. I've got<br>
about six people willing to work on this, and am *happy* to take the<br>
lead on getting this organized, once there's a system in place.<br>
<br>
I have a concept in my head for how I feel the overall process should work:<br>
<br>
1) The theme review (normal process, exactly as it is now) comes<br>
first. No theme should be checked for accessibility unless it's<br>
actually approvable for the theme repository already.<br>
2) Once a theme review is complete, and the theme is approvable, if it<br>
uses the 'accessibility-ready' tag, it will be shunted to a queue for<br>
accessibility review.<br>
3) Once that audit is complete with any required updates, the original<br>
theme reviewer should get a final check (?) (in case a new problem is<br>
introduced during accessibility updates), then the normal process can<br>
continue.<br>
<br>
This, to me, seems to minimize the alteration to existing work flow<br>
and also ensures that the A11y volunteers aren't wasting time<br>
reviewing themes that may never be approved anyway.<br>
<br>
I'm hoping to move this forward relatively quickly, if possible - I<br>
know about a half-dozen people currently working on building<br>
accessible WordPress themes intended for the directory. They're mostly<br>
accessibility specialists teamed up with WordPress developers, so this<br>
could be a great test of the audit process.<br>
<br>
Best,<br>
Joe Dolson<br>
<br>
On Wed, Nov 14, 2012 at 2:34 PM, Joe Dolson <<a href="mailto:design@joedolson.com">design@joedolson.com</a>> wrote:<br>
> True - but I think a combination of the presence of any other form<br>
> element with the absence of any label elements would be easy enough,<br>
> and would be sufficiently accurate.<br>
><br>
> Best,<br>
> Joe<br>
><br>
> On Tue, Nov 13, 2012 at 7:10 AM, esmi at quirm dot net <<a href="mailto:esmi@quirm.net">esmi@quirm.net</a>> wrote:<br>
>> on 12/11/2012 16:08 Joe Dolson said the following:<br>
>><br>
>>> A couple additional (and hopefully very rare circumstances) could be<br>
>>> screened programmatically -- a complete lack of <label> elements or<br>
>>> <h*> heading elements would be an automatic fail, as well. We may not<br>
>>> be able to verify that the elements are used correctly automatically,<br>
>>> but if they were absent, that would be a definite violation.<br>
>><br>
>><br>
>> Not sure about checking for label elements. As far as I recall, there is no<br>
>> mandatory requirement for a theme to include it's own searchform.php or<br>
>> comment.php files. So I'd imagine it's quite feasible for a theme to be<br>
>> submitted without any label elements. Also a niche theme might be aimed at<br>
>> page-only, no comment, sites. so, again - no need for a custom comment form.<br>
>><br>
>> That said, the core comment form needs a good overhaul in terms of<br>
>> accessibility, so I'm not sure how we'd handle any theme that simply pulled<br>
>> the core form - especially since the fixes are pretty easy at the theme<br>
>> level. Ideally, such a theme would not warrant the accessibility-ready tag.<br>
>><br>
>><br>
>> Mel<br>
>> --<br>
>> <a href="http://quirm.net" target="_blank">http://quirm.net</a><br>
>> <a href="http://blackwidows.co.uk" target="_blank">http://blackwidows.co.uk</a><br>
>> _______________________________________________<br>
>> theme-reviewers mailing list<br>
>> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
>> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
><br>
><br>
><br>
> --<br>
> ==================<br>
><br>
> Did I help you with one of my plug-ins? Donations keep support<br>
> possible! <a href="http://www.joedolson.com/donate.php" target="_blank">http://www.joedolson.com/donate.php</a><br>
><br>
> ==================<br>
><br>
> Joseph Dolson<br>
> Accessibility consultant and WordPress developer<br>
> <a href="http://www.joedolson.com" target="_blank">http://www.joedolson.com</a><br>
> <a href="http://profiles.wordpress.org/joedolson" target="_blank">http://profiles.wordpress.org/joedolson</a><br>
<br>
<br>
<br>
--<br>
==================<br>
<br>
Did I help you with one of my plug-ins? Donations keep support<br>
possible! <a href="http://www.joedolson.com/donate.php" target="_blank">http://www.joedolson.com/donate.php</a><br>
<br>
==================<br>
<br>
Joseph Dolson<br>
Accessibility consultant and WordPress developer<br>
<a href="http://www.joedolson.com" target="_blank">http://www.joedolson.com</a><br>
<a href="http://profiles.wordpress.org/joedolson" target="_blank">http://profiles.wordpress.org/joedolson</a><br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</blockquote></div><br></div>