Hi Lisa, > To meet new user needs we may need new tools and reviews may need to acquire new skills and knowledge. Which is fine, perhaps we can clarify that it means available at the time of publication? New tools, especially if they “take a day” from a programmer would need to be available at the time of publication, for the reasons I outlined in the last email. > Also new tools will come as soon as we know a SC will be accepted. in other word at CR. With WCAGs current history it will not come before then. Can you point to a previous example? I.e. where a tool that didn’t exist was required to meet an SC wasn’t available until after CR? The closest I can think of is ARIA in WCAG 2.0, but it wasn’t actually required to meet the SCs. It is very difficult to deal something in CR which then has to be pulled because no one has created a tool, the whole timeline goes back a step. The way the W3C prefers to work is to have working prototypes/code created prior to specs. This has been a hard-learned approach [1]. I suggest that if an SC needs a tool, we work up the SC template and go through the initial process. That could be accepted on the condition that a tool will be available. If it does not become available then the SC will be removed before CR. It would also help to put those SC(s) first so people have more time to work on the tools, I’ll make a note of that. Cheers, -Alastair 1] Accessibility example for what should be a ‘simple’ thing, the naming algorithm. https://www.linkedin.com/pulse/future-accname-spec-planning-strategy-functional-using-garaventa/
Received on Thursday, 7 March 2019 16:52:12 UTC