Re: CSS Accessibility Task Force commissioned

On 13/10/2016 11:59 PM, James Craig wrote:
>
> I've had a little more time to thing about the concerns I raised at TPAC.
>
> I do see value in tracking occasional accessibility review of the 
> various CSS deliverables, so I am optimistic about this task force, 
> but will outline my concerns below.
>
> *1. Use GitHub, Avoid Email Proliferation*
>
> As mentioned in the TPAC meeting, I'd prefer any accessibility 
> concerns with CSS be raised as individual GitHub issues against each 
> relevant spec, rather than more email discussion on a new list.
I think many times that will happen and of course individuals are free 
to do so, but the task force was created to provide a forum to explore 
issues where there isn't an existing spec against which to file issues, 
or to explore issues that seem to cross several specs. It's an important 
supplement to what you suggest.
> Conference calls should also be rare. My recollection is that the CSS 
> WG members and the proposers of this CSS Accessibility Task Force 
> agreed to that stipulation for this task force.
The working groups agreed that the task force will support asynchronous 
participation, but also that it may hold teleconferences if deemed 
useful. A schedule, or emergent frequency of "as-needed" 
teleconferences, will be found based on the preferences of the active 
participants once it's fully up and running. The group will support and 
respect your stated participation preferences, and it's important to 
good cooperation that you also respect other peoples' preferences. It's 
not an expectation that every participant will use every available 
channel of the task force; that's one reason we routinely provide 
multiple channels.
>
>
> *2. An Editor's draft of a CSS-AAM spec is premature. I'm not 
> convinced it should exist at all.*
>
> The SVG-AAM and HTML-AAM documents provide mappings between elements 
> defined in each specification, and the way those elements are exposed 
> to platform accessibility API. For the most part, these mappings are 
> not defined by the Working Group, but by the platform developers. 
> These mappings are subject to change, and therefore the HTML-AAM and 
> SVG-AAM should be informative living documents, rather than Rec Track 
> static documents. I've previously raised this problem to the ARIA 
> Working Group.
>
> As CSS does not define any elements, I see little to no value in a 
> CSS-AAM (CSS to Accessibility API Mapping) document. Mappings would be 
> defined by the language the CSS was styling, not by CSS itself. There 
> are a number of accessibility implications to various CSS features 
> (for example, layout/navigation order implications and generated 
> content) but I'm confident that each of these can be addressed by 
> small informative or normative additions to each of the relevant CSS 
> specs.
The name "CSS-AAM" might not be the best placeholder name, but it comes 
out of wanting to do "similar sorts of stuff" to what's being tackled in 
other Accessibility API Mappings. We have stated all along that we 
expect much of what's developed to migrate to other resources, which 
could be CSS modules or accessibility-specific guidance, normative or 
not. We don't know enough to say exactly what will happen, that will 
emerge through the work of the task force.

I will say that, while CSS does not have elements and attributes, there 
are features that may need to be exposed to accessibility APIs, which is 
why a CSS-AAM did not seem completely off base. The main example that 
comes to mind is generated content. Whether in the end an accessibility 
API mapping will be the solution is to be determined by the task force, 
but the concept of an AAM was a starting place.
>
> It also worries me that there would be a draft spec created before any 
> task force members had decided what should go in this document. Right 
> now it's just a blank copy of the Core-AAM from ARIA. Adding this 
> document to a repo at this early stage feels like unnecessary 
> bureaucracy and overhead rather than progress.
As you note, this is an empty draft just to have a place to collect 
notes. It was a specific request to have a repository available for 
issue collection and this was a component that had already been started 
in the ARIA WG. There will be a desire for draft documents at some stage 
so we need some repository. As I said in my introduction message, 
materials may migrate and other repositories created, but we have to 
start somewhere. And since I'm the one who has to deal with any 
bureaucratic effects of this, I don't see how the existence of the 
repository should be viewed as harmful to you or the progress of the 
task force.

Michael
>
> James
>
>
>
> On Sep 30, 2016, at 8:26 AM, Michael Cooper <cooper@w3.org 
> <mailto:cooper@w3.org>> wrote:
>
>> At last week's joint meeting between APA, ARIA, and CSS at TPAC I 
>> took an action to set up some infrastructure for the CSS 
>> Accessibility Task Force:
>>
>> https://www.w3.org/2016/09/20-css-minutes
>>
>> This is now done. Key resources:
>>
>>   * Home page, mainly as a place to link to everything else -
>>     https://www.w3.org/WAI/APA/task-forces/css-a11y/
>>   * GitHub repository for spec development, wiki, and issue tracking
>>     - https://github.com/w3c/css-aam
>>   * Mailing list - public-css-a11y@w3.org (archives at
>>     http://lists.w3.org/Archives/Public/public-css-a11y/)
>>   * Editors' draft of CSS-AAM - https://w3c.github.io/css-aam/
>>   * List of task force participants -
>>     https://www.w3.org/2000/09/dbwg/details?group=94039&public=1
>>
>> Some of the above may evolve as work progresses, particularly 
>> specific GitHub repositories or deliverables, but for now the above 
>> repository is where the task force can track issues. Participants in 
>> the task force are automatically subscribed to the mailing list.
>>
>> I added people to the task force who I could pick out of the minutes 
>> of last week's meeting. If you'd like to participate in the task 
>> force and don't see your name in the participants list above, just 
>> let me know and I'll add you.
>>
>> Next steps will be for the WG chairs to pick facilitators for the 
>> task force, editors for initial deliverables, and then for it to 
>> begin work. Activity around that will take place on the 
>> public-css-a11y mailing list to start; this message to the groups is 
>> just to let everyone know it's up and running.
>>
>> Michael
>>