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

Hi Phill,

 

Thanks for this. It appears that there is growing support for the idea that
WAI perhaps need to re-invigorate our efforts around the ideals of ATAG and
UAAG more (and certainly Authoring Tools, which more than one commenter has
noted already). I will be sure to ensure that this is captured as the
valuable feedback it is for the larger "WAI 20202" discussion

 

Returning to the shorter-term discussion of what do we do now, today
(tomorrow, this month, this fiscal quarter), your response highlighted the
words new devices and new technologies. Does this mean then that you believe
that Option 1.2 WCAG 2.0 plus extensions by technology or platform
<https://www.w3.org/WAI/GL/wiki/WCAG_Next_Possible_Models/Model_4>  is your
preferred way forward? I'm trying to bring focus to the immediate need we
are facing now: the fact that we are creating new (potential) Success
Criteria, new "Best Practices", new Techniques, etc. The question I want to
look at closely here is what exactly are we going to do with that material?
How do we "publish" it, and under what model?

 

Thanks!

 

JF

 

From: Phill Jenkins [mailto:pjenkins@us.ibm.com] 
Sent: Saturday, April 9, 2016 7:50 PM
To: WCAG <w3c-wai-ig@w3.org>
Cc: Andrew Kirkpatrick <akirkpat@adobe.com>; Chaals McCathie Nevile
<chaals@yandex-team.ru>; David MacDonald <david@can-adapt.com>; John Foliot
<john.foliot@deque.com>; Jutta Treviranus <jutta.treviranus@utoronto.ca>;
WCAG <w3c-wai-gl@w3.org>; Jutta Treviranus <jutta.trevira@gmail.com>
Subject: 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  <https://en.wikipedia.org/wiki/ADAPT> ADAPTmovement that helped
start ADA].    

I recommend that the Essential Components of Web Accessibility [
<https://www.w3.org/WAI/intro/components.php>
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>
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
 <http://www.ibm.com/able> ibm.com/able
 <http://www.facebook.com/IBMAccessibility> facebook.com/IBMAccessibility
 <http://twitter.com/IBMAccess> twitter.com/IBMAccess




From:        Jutta Treviranus <jutta.trevira@gmail.com
<mailto:jutta.trevira@gmail.com> >
To:        WCAG <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> >
Cc:        Jutta Treviranus <jutta.treviranus@utoronto.ca
<mailto:jutta.treviranus@utoronto.ca> >, David MacDonald
<david@can-adapt.com <mailto:david@can-adapt.com> >, WCAG <w3c-wai-gl@w3.org
<mailto:w3c-wai-gl@w3.org> >, Andrew Kirkpatrick <akirkpat@adobe.com
<mailto:akirkpat@adobe.com> >, John Foliot <john.foliot@deque.com
<mailto:john.foliot@deque.com> >, Chaals McCathie Nevile
<chaals@yandex-team.ru <mailto: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>
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