Re: CSS Accessibility Task Force commissioned

On Oct 14, 2016, at 6:25 AM, Michael Cooper <cooper@w3.org> wrote:

> 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.

A general CSS GitHub issue would suffice then. Just don't tag it or title it with spec-specific keywords.

https://github.com/w3c/csswg-drafts/issues

>> 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.

My concern over this is that many of the decisions made in WAI conference calls are:

1. partially undocumented (scribes only get so much context) and therefore exclude potential hearing-impaired contributors
2. don't include the previous context of discussion or decisions re: the same topic

A number of ARIA decisions were made, then reversed because the no one on the call happened to remember the context that would have been accessible to someone reading a GitHub issue. The GitHub issue history has a nice bonus in that you can integrate well with links, patches, pull requests, or other issues.

>> 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.

I think I addressed that in my last statement above. No? 

"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."

>> 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

Why not add issues to the main CSS WG with the title pattern [css-a11y] or an #a11y keyword?

> 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.

Many of the modern incubation attempts have proven that low overhead is better for participants. It feels like unneeded overheard to to create a spec before the Task Force knows what the spec is intended to hold 

James