Re: Straw man list for WCAG.NEXT, another proposal...

> we must keep up with changes on the Web, if we don?t we pit Web 
accessibility requirements against innovation and functionality.

Yes agree, isn't that the whole point of the thread? to keep up with 
changes in technology and update WCAG accordingly?

> One powerful way to achieve agility ... is for policy, legislation, 
regulations and WAI WCAG to focus on authoring tool supports for 
accessibility.

Yes agree the accessibility community should focus on ensuring policy, 
legialation, and regulation focus or add focus on ATAG.  I'm defining "
authoring tool supports for accessibility" as equivalent to conforming to 
ATAG.  Having a policy that ensure an authroing tool conforms with ATAG is 
also dependent on WCAG since the tool's output has to conform with WCAG. 
The W3C WAI is not the accessibility community, but a part of it.  Nothing 
is nor should have been stopping the accessibility community from 
encouraging policies that encourage conformance with ATAG (except perhaps 
the community itself focusing on WCAG at the expense of ATAG). As example, 
Facebook, Office, Docs, Blackboard, etc. should all be asked to comply 
with applicable ATAG Success Criteria.  The same argument should be made 
for UAAG conformance by Firefox, Chrome, Safari, Edge, etc.  I believe the 
browser has more to do with many of the WCAG Level AA and AAA requirements 
than the web application. 

 > We don?t need to get everyone up to speed on changes, only technically 
literate developers that are responsible for authoring functions.

Yes agree the accessibility community should put the renewed focus on 
conformance with ATAG and UAAG .  It should be relatively easier to focus 
on the "technically literate developers", but it hasn't seen as much 
progress as WCAG conformance.  Why? One reason may be because there are no 
incentives or rules requiring conformance.  We seem to be in a position of 
"begging" for any slight improvements we can get.  How many of your 
institutions, agencies, universities, corporations, etc. even have any 
policies that encourage or require conformance with ATAG and/or UAAG?  We 
could start there and chain ourselves to the virtural bus. . . [this is a 
refernce to the early ADAPT movement that helped start ADA]. 

I recommend that the Essential Components of Web Accessibility [
https://www.w3.org/WAI/intro/components.php] needs another version 
specifically for policy makers.  It needs to better explain the dependency 
on the three and why enforcing conformance to only on one of the 3  (WCAG) 
is ineffective. 

Having said all this, the WCAG working group still has to and needs to 
"keep up with changes on the web" exactly because ATAG and UAAG both 
reference and depend on WCAG. 

1. I believe we still need "interpretations" of WCAG for new devices, for 
example, which of the Success Criteria should be applied to a smartwatch? 
all smart watches? 
2. I believe we still need "interpretations" of WCAG for new technologies, 
for example, which of the Success Criteria should be adjusted or extended 
to address gestures?  Should there be a gesture for all interaction 
options just like WCAG says there should be for keyboard?  Why and why 
not?  Ever try to use a browser based web app and do the equivalent of 
keyboard tab, arrow up and down, left and right, and open/close 
(expand/collapse) with gestures?  I give up and go dust off my laptop or 
find a really good bluetooth keyboard for my device.

Referring to the diagram posted on the wiki 
https://www.w3.org/WAI/GL/wiki/WCAG_Next_Possible_Models/Model_5
my two examples above seem to fit in mostly with the 3 task forces of 
Cognitive, Mobile, and Low Vision.  However, UAAG and ATAG need to be 
added to the diagram since many of the more effective and efficient 
solutions will in fact be in the browser and authoring tool, not the web 
content/app. The output of the 3 task forces need to also address changes 
to normative success criteria, understanding, and techniques for ATAG 2.1 
and UAAG 2.1.  Otherwise WAI is not following our own foundation on 
essential components and the larger accessibility community will have to 
endure the ripple effects we cause.

Anyway, my 2 cents.
___________
Regards,
Phill Jenkins, 
Senior Engineer & Business Development Executive
IBM Research - IBM Accessibility
ibm.com/able
facebook.com/IBMAccessibility
twitter.com/IBMAccess




From:   Jutta Treviranus <jutta.trevira@gmail.com>
To:     WCAG <w3c-wai-ig@w3.org>
Cc:     Jutta Treviranus <jutta.treviranus@utoronto.ca>, David MacDonald 
<david@can-adapt.com>, WCAG <w3c-wai-gl@w3.org>, Andrew Kirkpatrick 
<akirkpat@adobe.com>, John Foliot <john.foliot@deque.com>, Chaals McCathie 
Nevile <chaals@yandex-team.ru>
Date:   04/09/2016 07:35 AM
Subject:        Re: Straw man list for WCAG.NEXT, another proposal...



Hi all, 
I want to re-emphasize another strategy...

>> From: David MacDonald [mailto:david@can-adapt.com]
> 
>> I *don't* think we should be saying we'll have 2 or 3 new versions of 
WCAG in the next 3 years...
>> it is incredibly expensive and time consuming for stakeholders to 
update
>> policy, legislation, and their web sites every year?

David makes a good point, however, we must keep up with changes on the 
Web, if we don?t we pit Web accessibility requirements against innovation 
and functionality. If anyone requires innovation it is people who 
currently experience barriers to using the Web, especially people we 
didn?t consider in formulating the last two versions of WCAG. 

One powerful way to achieve agility without unsupportable ripple effects 
throughout the ecosystem is for policy, legislation, regulations and WAI 
WCAG to focus on authoring tool supports for accessibility. Regulators 
would  require that authoring tools support accessible authoring and 
require employers to provide authoring tools that support accessible 
authoring. This reduces the load on public regulators, means that every 
Web author does not need to become technically literate in the specifics 
of accessible code, and requires compliance by a group that is also 
creating new functions so they think about accessibility at the time of 
innovation.

This also reduces the barriers to responsive change in requirements. The 
change only needs to reach the developers of authoring tools (albeit 
authoring functions appear in many forms but fewer than there are Web 
authors). We don?t need to get everyone up to speed on changes, only 
technically literate developers that are responsible for authoring 
functions. 

The other issue this addresses is that authoring tools are currently a 
huge impediment to accessible authoring. Anyone motivated enough to try to 
make their Web content accessible has to fight with the tools and find 
tricks and hacks that are not part of the standard workflow. 

Regarding ripple effects, think about the impact of any function to 
support accessibility in a popular authoring tool such as Facebook, Word, 
or Blackboard ? countless authors who may have no idea about any of the 
technical details of WCAG will unconsciously comply as part of the natural 
workflow. 

Jutta

Jutta Treviranus
Director, Inclusive Design Research Centre
OCAD University