- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Tue, 28 Jul 2015 06:41:45 -0500
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: Sailesh Panchang <sailesh.panchang@deque.com>, Joshue O Connor <josh@interaccess.ie>, Jonathan Avila <jon.avila@ssbbartgroup.com>, WCAG <w3c-wai-gl@w3.org>
Hi Steve, The Chairs or Judy may be able to address the long range plan. Kindest Regards, Laura On 7/28/15, Steve Faulkner <faulkner.steve@gmail.com> wrote: > An important difference (I think) between the proposed WCAG extensions > mechanism and the HTML WG extensions mechanism is that the HTML extensions > were/are being produced in a situation where the core spec is being > actively developed and where appropriate extensions are merged into the > core. This is what happened with 2 extension specs I worked on: > > main element: http://www.w3.org/TR/html-main-element/ > alt techniques: http://www.w3.org/TR/html-alt-techniques/ > > Both of which were integrated into HTML5. > > With the WCAG extensions there appears to be no integration path as work on > the core (WCAG 2x) is not chartered. > > Also please note there is a difference between HTML extensibility ( > http://www.w3.org/TR/html5/infrastructure.html#extensibility-0) and HTML > extensions.(http://www.w3.org/html/wg/wiki/ExtensionSpecifications) the > latter being a WG process. > > > > -- > > Regards > > SteveF > Current Standards Work @W3C > <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/> > > On 27 July 2015 at 19:01, Sailesh Panchang <sailesh.panchang@deque.com> > wrote: > >> Laura, >> As I read through those references, I come away thinking that they >> seem to support the views I expressed in my last email. >> i. The example of HTML5 being extensible ... it is a spec for a >> technology, unlike WCAG2. Besides I understand apparently HTML5 has >> been written in a manner that permits extensions to be written. >> Even when a technology spec changes it can be a change like from ARIA >> 1.0 to ARIA 1.1 or HTML4 to HTML5. >> And about WAI-ARIA being a separate recommendation in its own right: >> Absolutely. But it is a technology spec that does "extend" HTML. Is >> that not how one should be interpreting "extensibility"? >> >> ii. In the minutes: >> "AWK: we have the post-wcag2 wiki. We need to look at those items to >> inform our decisions, as well as the work of the mobile and cognitive >> task forces". >> I think that is reffering to the scope for a new WCAG2.x. That can >> alter normative content of WCAG2 / add new stuff ... something that >> may not be accomplished via an extension. >> >> iii. "In that document, it says, an extension wouldn't impact a >> country's law that referenced WCAG 2.0 until the law changed to be >> WCAG 2.0 +". >> Exactly, there has to be a new WCAG like WCAG2.1 or WCAG3 and the law >> needs to reference that. Even today, there may be some state laws for >> accessibility that still reference WCAG1. >> >> So without specific examples, it is difficult to understand what >> extensibility means in the context of WCAG2 and how it can be >> implemented or what its impact might be. >> >> Thanks and regards, >> Sailesh >> >> >> >> >> On 7/27/15, Laura Carlson <laura.lee.carlson@gmail.com> wrote: >> > Hi Sailesh, >> > >> > For more background I believe that the extension idea was discussed at >> > the April 7, 2015 working group meeting. Check the minutes: >> > http://www.w3.org/2015/04/07-wai-wcag-minutes.html#item03 >> > >> > The HTML WG and modularity and extension info may also be useful: >> > http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#modularity >> > http://www.w3.org/DesignIssues/Principles.html#Modular >> > http://www.w3.org/html/wg/wiki/ExtensionHowTo >> > http://www.w3.org/html/wg/wiki/ExtensionSpecifications >> > >> > It seems that back in April, Josh and Michael did some work in the >> > Wiki on a WCAG Extensions Framework document: >> > https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework >> > In that document, it says, an extension wouldn't impact a country's >> > law that referenced WCAG 2.0 until the law changed to be WCAG 2.0 + >> > extension conformance claim. >> > >> > Best Regards, >> > Laura >> > >> > On 7/27/15, Sailesh Panchang <sailesh.panchang@deque.com> wrote: >> >> Josh, Laura et al >> >> Here is my take on your first question: "Can extensions modify WCAG >> >> 2.0 >> >> SC?" >> >> >> >> The term extensibility applies really to technologies and not to >> >> specifications like WCAG 2. >> >> WAI-ARIA extends HTML for instance because "The incorporation of >> >> WAI-ARIA is a way for an author to provide proper semantics for custom >> >> widgets to make these widgets accessible, usable, and interoperable >> >> with assistive technologies". >> >> I reviewed the references in Boland's email as well as Laura's and >> >> could not relate the term "extensibility" with specs like WCAG2. >> >> >> >> Just like WCAG1 evolved into WCAG2, WCAG2 can evolve into WCAG 2.1 or >> >> 2.2... or directly into WCAG3. >> >> WCAG 2 is a guideline or standard if you will, and is often >> >> incorporated / referenced into law. >> >> "Changing" WCAG2 by an extension may require changes to such laws too >> >> (also noted by Wayne). >> >> In a sense, WCAG2 has already extensibility built in through the 3 >> >> levels: A, AA and AAA. >> >> >> >> Jonathan's more concrete thought like, "For example, we might want to >> >> create a 2.5 touch gesture guideline similar to 2.1 for keyboard >> >> access" gave me a sense of what extensibility might refer to in the >> >> context of WCAG2. >> >> I would not call such a change an extension but WCAG 2.1 or 2.2 etc. >> >> ... a new recommendation entirely. >> >> And specifically with regard to the touch gesture guideline being >> >> suggested, I believe it is addressed by WCAG 2. Refer to >> >> "keyboard interface - interface used by software to obtain keystroke >> >> input >> >> Note 1: A keyboard interface allows users to provide keystroke input >> >> to programs even if the native technology does not contain a >> >> keyboard". >> >> In this context, also refer to WAI-ARIA goals in the Introduction[1] >> >> >> >> In short, I am not really clear of "extensibility" as it applies to >> >> WCAG2. >> >> Changes to WCAG2 can be done in increments so it is pushed out in a >> >> shorter time frame as compared to the complete overhaul from WCAG 1 to >> >> WCAG2. Such a change will permit to normative content of WCAG2 based >> >> on implementation experiences and new developments. >> >> 1. http://www.w3.org/TR/wai-aria-1.1/#introduction >> >> >> >> Thanks and regards, >> >> Sailesh Panchang >> >> >> >> >> >> On 7/27/15, Laura Carlson <laura.lee.carlson@gmail.com> wrote: >> >>> Hi Jonathan and all, >> >>> >> >>> The coordinated piece is under Harmonization section in the proposed >> >>> principles. They currently read: >> >>> >> >>> * "Extensions SHOULD NOT conflict with other WCAG 2.0 extensions >> >>> conformance requirements." >> >>> >> >>> * "Extensions SHOULD harmonize with other WCAG 2.0 extensions >> >>> conformance requirements." >> >>> >> https://www.w3.org/WAI/GL/wiki/WCAG_2_Extension_Principles#Harmonization >> >>> >> >>> Any ideas for improvement? >> >>> >> >>> Again, the meaning of the keywords SHOULD NOT and SHOULD are taken >> >>> from RFC 2119. >> >>> http://www.ietf.org/rfc/rfc2119.txt >> >>> >> >>> Thanks. >> >>> >> >>> Kindest Regards, >> >>> Laura >> >>> >> >>> On 7/26/15, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote: >> >>>> Joshue, >> >>>>> We look forward to your thoughts/input - minutes from the meeting >> >>>>> are >> >>>>> available. [1] >> >>>> >> >>>> I agree with the general consensus from the meeting. I was not >> present >> >>>> so >> >>>> I >> >>>> wanted to make sure you heard from me. One item that came up in the >> >>>> MATF >> >>>> was that we were thinking about creating guidelines within the scope >> of >> >>>> the >> >>>> 4 main principles. For example, we might want to create a 2.5 touch >> >>>> gesture >> >>>> guideline similar to 2.1 for keyboard access. We'd want to make >> >>>> sure >> >>>> that >> >>>> these conventions are coordinated between task forces. >> >>>> >> >>>> Best Regards, >> >>>> >> >>>> Jonathan >> >>>> >> >>>> -- >> >>>> Jonathan Avila >> >>>> Chief Accessibility Officer >> >>>> SSB BART Group >> >>>> jon.avila@ssbbartgroup.com >> >>>> >> >>>> 703-637-8957 (o) >> >>>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter >> >>>> >> >>>> >> >>>> -----Original Message----- >> >>>> From: Joshue O Connor [mailto:josh@interaccess.ie] >> >>>> Sent: Thursday, July 23, 2015 2:10 AM >> >>>> To: WCAG >> >>>> Subject: WCAG extension >> >>>> >> >>>> Hi all, >> >>>> >> >>>> On Tues call we discussed WCAG extensions, and I am bringing the >> >>>> topic >> >>>> to >> >>>> the list. >> >>>> We would like your input on these three main areas that we see are >> >>>> the >> >>>> main >> >>>> potential areas of contention: >> >>>> >> >>>> Some core questions, for WCAG extensions are: >> >>>> >> >>>> - Can extensions modify WCAG 2.0 SC? >> >>>> >> >>>> - Must conformance to 'WCAG 2.0 plus extension' be also backwards >> >>>> compatible >> >>>> with WCAG without extension? >> >>>> >> >>>> - Can extensions even conflict with each other? >> >>>> >> >>>> On Tues call for some general background we had general agreement >> that: >> >>>> >> >>>> For question 1: >> >>>> There was a general sense on the call of 'yes', an extension may >> >>>> alter >> >>>> the >> >>>> conformance requirement for a given SC. For some context, this would >> >>>> mean >> >>>> that an extension could increase WCAG conformance requirements but >> >>>> not >> >>>> decrease WCAG conformance requirements or difficulty in any way. >> >>>> >> >>>> For question 2: >> >>>> The sense from the group was 'yes'. Core WCAG is now and will always >> be >> >>>> stable and the basis for conformance, the extension may meet some >> >>>> new >> >>>> need >> >>>> that doesn't exist in legacy user agents and therefore this proposal >> >>>> may >> >>>> be >> >>>> considered to fit into our model of backwards compatibility. >> >>>> >> >>>> For question 3: >> >>>> The feeling was we want to reduce the potential for extensions to >> >>>> conflict >> >>>> in anyway, and co-ordination and supervision of TF work is therefore >> >>>> vital. >> >>>> We will work to ensure that TF facilitators are in tune with what >> >>>> each >> >>>> special group is doing, to reduce the potential for dissonance. >> >>>> >> >>>> To be practical however, we won't know until we start development of >> >>>> these >> >>>> extensions what the potential for conflict actually is. >> >>>> >> >>>> We look forward to your thoughts/input - minutes from the meeting >> >>>> are >> >>>> available. [1] >> >>>> >> >>>> Thanks >> >>>> >> >>>> [1] http://www.w3.org/2015/07/21-wai-wcag-minutes.html >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> -- >> >>> Laura L. Carlson >> >>> >> >>> >> >> >> > >> > >> > -- >> > Laura L. Carlson >> > >> >> > -- Laura L. Carlson
Received on Tuesday, 28 July 2015 11:42:13 UTC