View source for Comments on WCAG.Next Models

=Summary of Comments from the WAI-IG list= 
The [https://lists.w3.org/Archives/Public/w3c-wai-ig/2016AprJun/0014.html first email requesting comments] was sent to the WAI-IG (Interest Group) email list by John Foliot on 8 April, 2016.  Responses are split over multiple threads, but all may be viewed on the [https://lists.w3.org/Archives/Public/w3c-wai-ig/2016AprJun/ WAI-IG archive for April-June 2016]. As of 26 April 2016, this initial email had inspired 66 emails from 27 people.  

==Comments on Specific Options ==
===Option 1.1: Maintain WCAG 2.0 and add Normative Extensions ===
* Mark Malamud (8 April) Pro
* Chaals McCathie Nevile(8 April) - Con: too many options for organizations to decide what to conform to.
* Jason Kiss (13 April) - Con: Conformance is too complicated for regulators
* Gian Wild (17 April) - Con: too complex, people will choose just one and ignore the rest. Non-testable success criteria for cognitive are AAA, which is ignored.

===Option 1.2 WCAG 2.0 plus extensions by technology or platform ===
* Macintosh, Kristy (11 April) Pro: don't change WCAG -- too hard for conformance to change WCAG; add specialized documents for specific purposes (e.g. eLearning)
* Andrew Kirkpatrick (11 April) In response to Kristy : Updating WCAG doesn't change government requirements. Ontario will still require WCAG 2.0 until Ontario decides to change to a future version. WCAG 2.0 won't change. 
* <accessys@smart.net> (11 April) Con: This could result in people with disabilities having to switch hardware platforms because advanced accessibility requirements exist only for that platform.  (additional email with more detail on this Con)
* Jason Kiss (13 April) Con: contrary to the more integrated, holistic and agnostic approach initiated with WCAG 2.0.
* Gian Wild (17 April) - Con: People often don't know what technology they are using

=== Option 2.1 WCAG 2.x by Task Force: based on a WCAG 2.0 plus the work of an individual task force ===
* Chaals McCathie Nevile(8 April) "Con: it lets the  perfect, which is probably unachievable, be the enemy not only of good,  but even of "better than it is now"."
* Jason White (10 April) Con: "The value and longevity of WCAG 2.0 owes much to the technology-independence of its success criteria"
* Jason Kiss (13 April) Con: contrary to the more integrated, holistic and agnostic approach initiated with WCAG 2.0. It would group or isolate Success Criteria into separate disability and/or technology-specific collections, and for that reason should be avoided.
* Gian Wild (17 April) - Con: Too confusing, hard to tell the difference from Option 1.1

=== Option 2.2: WCAG 2.x by date across Task Forces as work is ready ===
* Paul Adam (8 April) - Pro
* Jim Tobias (8 April) - only more contextual update is needed to prevent fragmentation by other groups
* Chaals McCathie Nevile(8 April) "It helps the groups working on extensions to focus on incrementally improving and on relevance, since  it is clear to them that they will need to work with not only the existing  guidelines (as they are at any given time), but also with other groups  focusing on a different set of needs, to make sure they describe their  requirements in a way that works for everyone."
* David McDonald (11 April) Con: If a task force is under-represented because their work isn't done then it will continue to disenfranchise that group. 
* Mike Elledge (11 April) periodic updates "provide a benchmark for a collection of new techniques, success criteria and failures that could be easily referenced, for review and implementation." Discourages cherry-picking requirements. Smoothes way for WCAG 3.0.
* accessys@smart.net (11 April multiple) better by readiness than a date, but people need deadlines
* Jason Kiss (13 April) Most in favor of option 2.2 considering all the arguments.
* Gian Wild (17 April) - Pro.  Perhaps every 2 years instead of every year. 
* Lisa Seeman (20 April) - Pro.  Must insure that special interests don't delay an SC to exclude it. 
* Makoto Ueki (26 April) - Pro. Don't modify WCAG 2.0.  Japanese law will not have a problem with version number.

=== Option 3.1: Consolidating the work of all the task forces into one Extension that would advance to Recommendation status within W3C. === 
- also known as [https://www.w3.org/WAI/GL/wiki/WCAG_Next_Possible_Models/Model_5 Model 5] (wiki of proposal)
* Jason White (8 April) Pro
* David McDonald (8 April) Pro
* David McDonald (8 April) Pro - it is expensive and time-consuming for stakeholders to have to continually update with multiple versions.
* Mike Elledge (11 April) Pro
* Katie Haritos-Shea (11 April) Pro: Task Forces that finish early can help other TF.  
* Chaals McCathie Nevile(9 April) Con: It is expensive to have bad accessibility and no one is forced to update. Both WCAG 2.0 and WCAG 2.x will be valid for years to come.  It is holding back societies who want to improve accessibility if we are not giving the latest information that we know.  It would take a long time to get the all-inclusive single version. We are always working on new things. 
* Jutta Treviranus (9 April): Con: We must keep up with innovation especially for disabilities that were not considered in WCAG 1.0 & 2.0. 
* David McDonald (9 April) - add a deadline for the one extension, otherwise fall back on the multiple extension model (1.1) 
* Andrew Kirkpatrick (11 April) - risky that it would take too long; a Task Force could be delayed, there is always reason to postpone to add another feature; we need to hear from policy-makers about more frequent updates.
* Jason White (11 April) supports Katie
* Jason Kiss (13 April) - Con: Ideal, but not practical. It will take too long to reach consensus
* Makoto Ueki (26 April) - Pro.

==Other Comments ==
=== Avoid disability specific extensions, focus on serving universal design for multiple communities ===
* Jason White (8 April)
* Mark Malamud (8 April) "focus of WCAG 2.0, which shifted from the tech to the person (i.e., the person/tech interface challenges), by organizing around the Principles."
=== Use a two year revision cycle ===
* Chaals McCathie Nevile(9 April) 
=== Do more with Techniques to stay current ===
* David McDonald (9 April)
=== Focus more on Authoring Tool support ===
* Jutta Treviranus (9 April)
* Chaals McCathie Nevile(9 April) 
* Liddy Nevile (9 April)
* Jason White (9 April)
* Phill Jenkins (10 April)
* Jason White (10 April)
* Jason White (11 April) - must include javascript tools
=== Smaller is Easier (Agile) ===
* Chaals McCathie Nevile(9 April) 
=== We need better Accessibility Review tools ===
* Emmanuelle Gutiérrez y Restrepo (9 April)
=== Update "Essential Components of Web Accessibility" for policymakers ===
* Phill Jenkins (10 April)

=== Include User Agent Accessibility Guidelines (UAAG) 2.0 ===
* Phill Jenkins (10 April)
* John Foliot (10 April)
* Jason White (9 April)
=== WCAG needs "Best Practices" ===
* David McDonald (11 April multiple) - Better than AAA
* John Foliot (11 April)
* John Foliot (11 April) - could be a new level of WCAG guidance
* Paul J. Adam (11 April) - call them "Future Success Criteria"
* Katie Haritos Shea (11 April) - Best practices could become normative after an update
* Mike Elledge (11 April) - Best practices could become normative after an update
=== Get feedback from Government/Legal/Regulators ===
* Alan Smith (11 April) - need to get feedback, sounds like it would not interfere with regulation
* Katie Haritos-Shea (11 April) - Lainey Finegold is talking with Justice Dept lawyers, they are interested. 
* Phill Jenkins (11 April) - must get input from Access Board, timing feedback is important, updating WCAG and updating regulations are two separate processes. 
* John Foliot (11 April) - remember that regulators are a constituency, but not the only constituency.  Our core constituents are people with disabilities and we should not hold back updating guidelines for government regulations.  
* Lainey Feingold (11 April) - willing to coordinate meetings with lawyers, including Canadian lawyers, would need a 2-3 paragraph summary for getting their opinions.
=== Need to consider people w/disabilities at poverty level ===
* Balusani, Shirisha (12 April) - people running older versions or use free software. Guidelines must consider that. 
* accessys@smart.net (12 April) - some vendors make accessibility hard deliberately
* Jon Avila (12 April) prices dropping for tablets, there are many people using the Android flaver of Linux.

== Other Individual Comments ==  
* Katie Haritos Shea (11 April) 
** Continue to understand and support the accessibility standards needs and logistics of industry, legistlation and governments
** Continue to provide the education and outreach that this particularly unique set of standards needs via the W3C
** Collaborate with universities and non-profits in the education space to increase accessibility career offerings and degrees – as well as public education and outreach
** Look at providing an updated standard that incorporates requirements of WCAG, ATAG and UAAG – such as a WAI 1.0 – every 3 years (could be 2, but no more than 3)
** Promote strongly the *best practices approach* (for not yet required Success Criteria) for keeping current in practice with each new iteration of the standard
* Tim Boland (12 April)
**Some references which may be relevant to aspects of the current thread are given following: W3C Quality Assurance Framework - Specification Guidelines - W3C Recommendation 2005 - goal is to help W3C editors write better specifications (discusses extensibility, among other topics) https://www.w3.org/TR/qaframe-spec/
** Variability in Specifications - WG Note 2005 - details some of the most important concepts related to conformance when designing a specificationhttps://www.w3.org/TR/spec-variability .  It might be interesting to consider in these discussions whether the spirit or tenets of these documents are being satisfied
* Balusani, Shirisha (12 April)
** I agree with John's line of thought. But I would like to pose these questions about the existing rules and AT’s:
**# What versions of the different browsers are supported? I mean when we test applications for accessibility, check the compatibility of screen readers versions with the browsers versions?  For example, up to what previous version of JAWS should be tested with IE (version), similarly NVDA (V) with FF (V), Chromevox (V) with Chrome(V), Voiceover with safari , and  Dragon, Windows eyes etc.
**# Also some of the existing WCAG rules are difficult to understand as all information is not available at one place. Providing examples will help users to get better understanding of the rules.  Provide examples of accessible widgets in the rules. This would be really helpful for developers.
**# A few times I encountered accessibility issues but didn't find appropriate rules to map to. For example: When there is an interactive data (canvas), I don't want screen readers to read the text related to this interactive element as they are not accessible to the screen readers. If a part of data associated with the interactive element read by AT's then it will confuse the AT users. Note: There is an alternative method provided to get that data for the AT users. In this scenario I don't know to which rule I should map this failed scenario to. (Jon Avila replied to use SC 4.1.2) 
* Sean Murphy (12 April)
** This could be out of scope, but what about the standard for UX desktop that is in draft? This is something that needs to be developed. As GUI based applications are still present and aren't going away for a while yet. If there was a solid standard for GUI UX (user interface design) that was vendor independent. This would make the accessibility gap process easier.
**# Also some of the existing WCAG rules are difficult to understand as all information is not available at one place. Providing examples will help users to get better understanding of the rules.  Provide examples of accessible widgets in the rules. This would be really helpful for developers.
**# A few times I encountered accessibility issues but didn't find appropriate rules to map to. For example: When there is an interactive data (canvas), I don't want screen readers to read the text related to this interactive element as they are not accessible to the screen readers. If a part of data associated with the interactive element read by AT's then it will confuse the AT users. Note: There is an alternative method provided to get that data for the AT users. In this scenario I don't know to which rule I should map this failed scenario to.
**# Jon Avila (12 April) responded SC 4.1.2
* Jason Kiss (13 April)
** On that note, I’d like briefly to suggest that the Mobile Accessibility Task Force consider renaming itself and/or moving away from an explicit focus on “mobile”. The Task Force’s proposed Success Criteria are almost all about different input devices and interfaces (i.e., touch, gesture, speech) that are not specific to mobile devices, and so the reference to and focus on “mobile” is misleading and inconsistent with WCAG’s general approach to describing and addressing accessible outcomes and interaction.