- From: Michael Cooper <cooper@w3.org>
- Date: Fri, 14 Oct 2016 09:25:00 -0400
- To: James Craig <jcraig@apple.com>
- Cc: Accessible Platform Architectures Working Group <public-apa@w3.org>, ARIA <public-aria@w3.org>, CSS WG <www-style@w3.org>, Chris Lilly <chris@w3.org>, Bert Bos <bert@w3.org>, Rossen Atanassov <ratan@microsoft.com>, Alan Stearns <stearns@adobe.com>, "Richard S. Schwerdtfeger" <schwer@us.ibm.com>, Janina Sajka <janina@rednote.net>
- Message-ID: <c66a9908-73e4-db3c-322b-5ee2020f7690@w3.org>
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 >>
Received on Friday, 14 October 2016 13:25:15 UTC