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

I think ATAG and UAAG are great standards that are moving the bar forward.
Eclypse, Sublime, Dreamweaver, Visual Studio are incorporating many of ATAG
requirements. The ARIA spec is built onto auto complete for example...

ATAG and UAAG have new versions fresh off the press thanks to your hard
work and many other volunteers. They are mature documents that have a small
audience, (about 10 browsers, and 200 or so authoring tools) but that small
audience affects millions of users. I'd love to see ATAG and UAAG required
by law. I'm guessing the authoring tools are seeing that as a possibility,
because currently, I think every major authoring tool has hired an
accessibility director or has enlisted outside support or has a committee
that is looking at ATAG. This includes Facebook, LinkedIN, Twitter,
Wordpress, Drupal, Microsoft, Adobe, SAP, Oracle, etc... these tools and
companies cover about 80% (?) of all authored content on the web...

HTML5 has a section for Browsers and a section for authors, maybe we can
adopt that model going forward.... but I thought that is what WAI has
always done... had three tracks Authors, user agents and authoring tools.

I believe since our group will be the only one still chartered, we will
fully explore the integration of UAAG and ATAG for WCAG 3, which is related
to what used to be called WAI2020... it's a long term project.

In the meantime we have 3 task forces who have identified gaps in WCAG 2
... Should we not proceed with a 2.x which incorporates their
recommendations?

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Sat, Apr 9, 2016 at 8:25 AM, 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
>
>
>