- From: Jutta Treviranus <jutta.trevira@gmail.com>
- Date: Sat, 9 Apr 2016 08:25:39 -0400
- 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>
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
Received on Saturday, 9 April 2016 12:26:12 UTC