- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Mon, 27 Jul 2015 14:01:32 -0400
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: Joshue O Connor <josh@interaccess.ie>, Jonathan Avila <jon.avila@ssbbartgroup.com>, WCAG <w3c-wai-gl@w3.org>
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 >
Received on Monday, 27 July 2015 18:02:00 UTC