Re: WCAG Agenda April 7 2015

Agree.

Extensions don’t change standards, or add to the standards.   For example SVG is an extension of HTML but doesn’t change the HTML standard nor what it takes to conform to the HTML standard.  

Also, agree that WCAG was meant to be flexible enough to apply to different platforms, devices, etc.   In fact the WCAG2ICT task force looked at what it took to apply WCAG to e-documents (not on the web) and software in general.   Their conclusion after a year of work was that it did apply with basically just changing the words Web to documents and software.    (they did find that a couple provisions that talked about “sets of” didn’t occur much (rarely) in docs and especially software.  But when they did occur - they would still apply as written.   
 It is important to note that the group also concluded that WCAG didn’t apply directly to “closed platforms” because WCAG assumed the ability to use AT to provide access.  Closed functionality is defined as functionality where AT is prevented from being used by  physical design or policy.   So the  WCAG2ICT task force concluded that for closed functionality — the effects of WCAG (esp the “programmatically determinable” provisions - where AT was assumed) would have to be provided in other ways  - since AT can’t be used with closed functionality. 
 WCAG obviously doesn’t provide the guidelines for the hardware parts of devices either — so those need to be added to WCAG  (and are in 508) along with platform requirements. 


Perhaps some of what we are talking about can be addressed with new techniques for meeting existing provisions in different platforms or devices.  
while others might be extension provisions. 

but even in an extension - if conformance is involved - the provisions all need to meet the normal provisions for a ‘requirement’ or success criterion.     

It will be interesting to see if we are able to identify any new provisions that meet the usual criteria for being a requirement.
Here are 4 - (I might have forgotten one)
Is it measurable and testable? - (e.g. clear criterion that are pass fail) (you can’t require something if the person cannot determine if they have passed)
Is it clear/internally consistent —  if you have 10 people evaluate 20 pieces of content against a provision - there will be high level of agreement on whether the pieces of content meet the criterion (e.g high inter-rater reliability)  (It isnt fair if people can’t generally agree on whether something passes or not)
Can the provision can be applied across 
all types of pages (static, dynamic, web apps),
all levels of content (simple through technical such as physics sites, medical sites etc.) 
all devices that the content will be shown on (or evaluated on)  
WITHOUT fundamentally changing the content, its purpose or its effectiveness.  (e.g. rewiring a medical or physics site 
Is it practical to apply this to all web sites in the world (that we want to use the guidelines)
(e.g. we did not include a sign language alternative for all web content in WCAG 2.0 because the cost would be enormous and there simply are not enough people skilled in transforming all sites into sign language to provide re-presentation in sign language of even a small fraction of all the web pages — even if the web wasn’t changing every day).    ( similar problem would occur if we wanted all web pages to be in plain language.   Trying to convert just one site into plain language points out the enormous skill and time required to do this.  We did it for a simple 4 page “research subject disclosure form” and it took days and our whole team.   And this would be true for any complex site.  

In WCAG 2.0 we had many more things that we identified that could make this type or that type of page more accessible to different groups.  And we included many as advisory - and need to keep identifying and documenting more.  But before it can be a general requirement for Web pages - it would need to meet all of the above - and that was much harder.   A smaller set.

In thinking about creating any guidelines for general application (all websites) the above list of 4 criteria is a good first test to see if the idea/ provision can qualify — or whether it would need to be an advisory technique to be applied when and where appropriate.  (We ran into this in WCAG many times - and it is very painful to not be able to include good advice because it couldn’t be a provision.  In at least one case we included a testable provision just so that we had a place to attache a lot of good advisory techniques that would couldn’t get in as success criterion because we couldn’t satisfy the criterion for doing so. 

IDEA  - Perhaps we can create more requirements if we constrain the scope of their application.
for example - Guidelines for general, non-technical information, transaction and shopping pages
If we were talking about general information pages — or general transaction pages  (e.g. shopping) we could come up with guidance that would be more far reaching (and still practical)  than if we tried to create guidelines for application across all web sites and content types (where many of the provisions would not be possible highly technical information or highly complex operations like programming or creating spreadsheet-like formulas

Just a thought.  Perhaps we can push the envelop if we don’t try to include all types/sites in the envelope like WCAG had to.   

gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




> On Apr 5, 2015, at 9:16 PM, Mike Elledge <melledge@yahoo.com> wrote:
> 
> A couple of things come to mind for discussion. Are the extensions meant to be additions to WCAG 2.0 for specific contexts? Or are there instances where they might override WCAG 2.0 given a particular context? 
> By definition WCAG 2.0 is supposed to be flexible enough to apply to different platforms, devices and languages (no longer HTML-centric) on the web, but once we apply it outside of the usual context, for example, in automotive interiors or on something like Google glass, are all bets off? I like the idea of extensions being supplementary, but I think we have to be careful to avoid offering them as reinterpretations of existing WCAG criteria. Otherwise we will cause confusion as well as weaken the authority of WCAG 2.0. 
> 
> I think we also want to avoid re-writing WCAG every time a new use case appears. :^)
> 
> Mike
> 
> 
> On Apr 4, 2015, at 9:53 AM, alands289 <alands289@gmail.com <mailto:alands289@gmail.com>> wrote:
> 
>> Since WCAG 2.0 is stable and is also an ISO standard, is there a challenge in adding to it via extensions?
>> These are almost like revisions. 
>> 
>> Before we determine what they all should be we need to determine how to relate new things to the already approved WCAG 2.0 that governments and organizations are using. 
>> 
>> From the eyes of the user:
>> What authority do these new items have?
>> Why should I do them, all I really need to do is WCAG 2.0?
>> Who says these are related and required?
>> 
>> Best Regards, 
>> Alan
>> 
>> 
>> 
>> Sent from my Samsung Galaxy Tab®4
>> 
>> 
>> -------- Original message --------
>> From: Joshue O Connor <joshue.oconnor@cfit.ie <mailto:joshue.oconnor@cfit.ie>> 
>> Date:04/03/2015 7:43 AM (GMT-05:00) 
>> To: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>> 
>> Subject: WCAG Agenda April 7 2015 
>> 
>> The WCAG WG will be meeting on Tuesday, 7th April  2015  at 11AM Eastern US
>> 
>> (Length: up to 90 minutes)
>> 
>> Bridge: +1.617.761.6200  (US) Passcode: 9224#
>> 
>> IRC: irc.w3.org <http://irc.w3.org/><http://irc.w3.org <http://irc.w3.org/>>  port: 6665 channel #wai-wcag
>> 
>> Scribe list:https://www.w3.org/WAI/GL/wiki/Scribe_List <http://www.w3.org/WAI/GL/wiki/Scribe_List>
>> 
>> Agenda
>> 
>> 1)    TPAC final call
>> 
>> 2)    Extension model discussion:
>> 
>> Including the sub topics:
>> 
>> Background pointers
>> What type of extensions?
>> Will extensions be A, AA, AAA?
>> Will extensions conform to WCAG requirements for success criteria?
>> Categorisation of current open issues in the context of the extension model
>> 
>> 3) WCAG working group and public engagement/interaction
>> 
>> Thanks
>> -- 
>> Joshue O Connor/Andrew Kirkpatrick
>> WCAG working group co-chairs
>> 
>>