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

David,

This is an interesting suggestion.

Can you propose some details on how you would better promote the Techniques
forward through WCAG? Are we happy with the current process, or could that
be improved?  I agree that timely Techniques *are* ultimately more useful
for working developers, and this is a good model to address that.

But ultimately we will likely need to address new Success Criteria as well,
and so a suggestion of timelines and outcomes in that light is required as
well. If we Propose a WCAG 2.x using this model (rapid acceleration of
Techniques), how would you move to a full 2.x extension? You suggest
"...scrutinize the Success Criteria from these 3 task forces, and add them
when they are all ready", but would that be individually, or as a block?
And if as a block, when?

JF

On Fri, Apr 8, 2016 at 9:36 PM, David MacDonald <david@can-adapt.com> wrote:

> >>>As the Web develops, we constantly need to work on new things, and on
> improving the things that we sort of fixed already, as we learn more about
> the gaps and how to do better.
>
> My personal opinion is that we have a great mechanism for that.... it's
> called the "Techniques". We've added over 20 Aria Techniques and they are
> used, we've added over 120 since 2008 ... my guess is that other techniques
> we add, will also be used by motivated webmasters.
>
> The Success Criteria are very specific and most developers don't even look
> at them. They want the code, the examples, they want to know what to *do*,
> not the legal ease... That is why I think we should integrate into the
> techniques, all the work of the task forces as it comes in, and then
> scrutinize the Success Criteria from these 3 task forces, and add them when
> they are all ready. Hopefully, we'll have a list of candidate Success
> Criteria soon.
>
> I think this will give the public more confidence in us.
>
> I went through the first Mobile note and separated out candidate SC's from
> helpful advice and that was the genesis of what we are working with now on
> the Mobile TF. It took two days, but was well worth it. I hope to do that
> with the other two task forces soon.
>
> 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 Fri, Apr 8, 2016 at 8:04 PM, Chaals McCathie Nevile <
> chaals@yandex-team.ru> wrote:
>
>> Hi David,
>>
>> On Sat, 09 Apr 2016 01:02:55 +0200, John Foliot <john.foliot@deque.com>
>> wrote:
>>
>> 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...
>>>
>>
>> I don't think we'd get 3 revisions in three years, although I must admit
>> I'd like to believe we could do that. But I think a 2-year revision cycle
>> is a reasonable aim.
>>
>> it is incredibly expensive and time consuming for stakeholders to update
>>> policy, legislation, and their web sites every year...
>>>
>>
>> Sure. But first, they are not required to do so. WCAG 2.0, and for that
>> matter WCAG 1.0 are likely to be available as reference targets for years
>> to come.
>>
>> And second, and to me more important, it is also expensive *not* to
>> improve accessibility when we know how to do it.
>>
>> The model for WCAG (except sometimes for triple-A requirements, although
>> I'd like to see that change back in a few short years) is that every
>> checkpoint improves accessibility for people, and that they are designed so
>> that they don't do it at the expense of someone else.
>>
>> WCAG doesn't set a minimum bar, it's a technical document explaining the
>> requirements that we have worked out. So if we have worked out how to stop
>> excluding some people from some of the Web, I think it is important to
>> express that, as a latest version of the Recommendation.
>>
>> In general, stakeholders aren't bound to "shift their goalposts",
>> updating policy, technology, practice, etc, because we learned more about
>> how to make the web work better.
>>
>> In some places, WCAG (or some equivalent) is set as the requirements, and
>> very rightly changes to those requirements can be made or not according
>> local policy.
>>
>> In others, and notably Australian and subsequently British discrimination
>> law works like this, the requirement is to do what is necessary to remove
>> barriers.
>>
>> If we know there are things that can be done but don't explain them, we
>> are holding back societies who are actively deciding to invest in ensuring
>> the greatest possible participation, which it is our goal to facilitate
>> with the necessary technical information.
>>
>> As a final point, while it is indeed expensive to change things, the
>> bigger the change the more expensive it is. If we make incremental updates,
>> rather than dropping the massive shift that was understanding the change
>> from WCAG 1.0 to WCAG 2.0, I think we'll be moving at approximately the
>> natural "average" rate of development in the industry. Which will
>> considerably ease the cost of adapting.
>>
>> if we're not ready to incorporate all the task force work then lets wait
>>> to release the next version we are
>>>
>>
>> I strongly suspect there is enough that we don't know how to do to keep
>> the task forces busy for a decade working with today's technology - which
>> will of course be superseded by then.
>>
>> Meanwhile in a few years since WCAG 2.0 was more or less frozen, the
>> explosion in the diversity of screen size and resolution means that I, who
>> don't wear glasses when working, regularly have to use more than the
>> WCAG-minimum 200% zoom in order to do my job. And the off-the-shelf tools I
>> have all happily go beyond that 200%.
>>
>> Likewise, the requirement for keyboard operability isn't actually what
>> makes me able to use a small phone, and yet the technology and techniques
>> are out there as reasonably common, but not universal, knowledge in the
>> industry.
>>
>> Currently there is *no* model that says we will have one important 2.x
>>> release that incorporates *all* the task force work. I think that needs to
>>> be discussed... I put up a WIKI page here, and would like to see this added
>>> to the straw man list...
>>>
>>
>> It makes good sense to add it to the strawman list. That said, I don't
>> believe we'll get to a situation in the next decade - any more than we have
>> in the last - where we think we've really got everything nailed down and
>> know it all. As the Web develops, we constantly need to work on new things,
>> and on improving the things that we sort of fixed already, as we learn more
>> about the gaps and how to do better.
>>
>> cheers
>>
>> Chaals
>>
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>>  chaals@yandex-team.ru - - - Find more at http://yandex.com
>>
>
>


-- 
John Foliot
Principal Accessibility Consultant
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion