W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2016

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

From: Chaals McCathie Nevile <chaals@yandex-team.ru>
Date: Sat, 09 Apr 2016 15:46:08 +0200
To: WCAG <w3c-wai-ig@w3.org>, "Jutta Treviranus" <jutta.trevira@gmail.com>
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>
Message-ID: <op.yfnm66oms7agh9@widsith.local>
A big +1 to this.


On Sat, 09 Apr 2016 14:25:39 +0200, Jutta Treviranus  
<jutta.trevira@gmail.com> wrote:

> 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

Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Saturday, 9 April 2016 13:46:43 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 9 April 2016 13:46:43 UTC