No subject

issues -- mostly, these are

 - easily testable (don't require a screen reader for testing);
 - make a significant difference to the accessibility of the site
 - are specifically theme decisions and not user decisions

We're avoiding any commitment to specific guideline conformation,
since that isn't defensible when we aren't reviewing an actual web
site, and we are specifically not requiring code validation, as there
are some very beneficial choices that can be made for accessibility
that will not validate.

Some of these guidelines could be evaluated by Theme-Check; though
certainly not all. As is common with accessibility issues, some of
those checks would have to be only partially confirming: some things
can be automatically tested as failing, but not as passing.

Best,
Joe


On Fri, Sep 28, 2012 at 9:59 AM, Chip Bennett <chip at chipbennett.net> wrote:
> I see no reason that the WPTRT can't support this effort. However, doing so
> will require some up-front work and workflow changes.
>
> From a practical standpoint, here's what I think we would need for
> 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
>
> So really, the first step, #1, is creating the accessibility Guidelines in
> the Codex. Once those are defined, we can certainly go from there. Note
> that, in the end, to the extent that accessibility will require live-human
> verification, the WPTRT will need volunteers from the accessibility team to
> help with the reviews.
>
> Thanks,
>
> Chip
>
> On Fri, Sep 28, 2012 at 8:44 AM, Edward Caissie <edward.caissie at gmail.com>
> wrote:
>>
>> Well written Mel!
>>
>> Obviously there is passion behind this cause and support from "core" as
>> well ... it would seem the http://make.wordpress.org/accessibility group has
>> a strong position to lobby for an additional tag to be added to the theme
>> repository. Perhaps three tags: Accessibility-A, Accessibility-AA, and
>> Accessibility-AAA? Just some food for thought ...
>>
>> ... and you would have my support for a new tag(s) based on these
>> discussions, too.
>>
>>
>> Cais.
>>
>>
>> On Fri, Sep 28, 2012 at 8:39 AM, Bryan Hadaway <bhadaway at gmail.com> wrote:
>>>
>>> SOLD
>>>
>>> Okay, honestly, you've made a really solid case and I almost feel I want
>>> to do my part to help now. You've got me thinking about it (it's my
>>> obsessive nature) and now I'm considering making some of my themes as
>>> accessible as possible (which I think about in general, but perhaps not
>>> enough).
>>>
>>> I could go point by point and rebuttal and clarify a lot, but I feel a
>>> bit suffocated by your passion vs my somewhat interest (and slight laziness
>>> at the moment) in the matter and I really think it would be overkill to do
>>> so, so I'll just say my generalized open-ended way of speaking (and use of
>>> synonyms in my mind) often clashes with those that speak in very literal
>>> terms which I think is one of the biggest issues here as far as
>>> misinterpretation and misunderstanding and disagreement. Overall though
>>> you've made some great valid points that has changed my perspective in the
>>> matter, good work :).
>>>
>>>
>>> "Instead what is being suggested is an additional OPTIONAL review only
>>> for those who WISH to flag their submitted theme as accessible."
>>>
>>> This was obviously my biggest concern and you've clarified to the point
>>> that I think I'm on board. Perhaps themes that are tagged "accessible" (and
>>> to be accessible perhaps the criteria should be that at least x number of
>>> accessible features are in place or at least
>>> http://www.w3.org/WAI/WCAG1A-Conformance is met) could be placed in their
>>> own separate ticket category so reviewers know exactly what kind of
>>> attention the theme needs right away? If someone already suggested that,
>>> apologies (I'm in skim mode a bit).
>>>
>>> So, you've turned my stubbornness into a vote. I was wrong. There can be
>>> reasonable improvement in this area, I'm going to take a nap now and then
>>> analyze and update some of my themes with accessibility in mind.
>>>
>>>
>>>
>>> Bryan Phillip Hadaway
>>>
>>>
>>> Web & Graphic Designer
>>> calmestghost.com
>>> bhadaway at gmail.com
>>>
>>>
>>> Socialize: Facebook | Twitter | LinkedIn | Google+
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> 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