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

>Can you propose some details on how you would better promote the
Techniques forward through WCAG?

I think the new how to meet is a great start, and of course links from the
sufficient techniques section. Education and Outreach are doing a great job
lately, Tutorials, how to meet ... they want to work with us to get this
information out. I'm hoping in the future they will have a bigger part to
play in our Techniques.

>>>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.

I want this as much as anyone... I believe what it takes is for the few of
us who have experience writing success criteria to go through the cognitive
and low vision material and tease out possible success criteria... I did
this with the mobile note and it kick started us... got us over the hump of
having a bunch of helpful advice to having something for consideration in
WCAg 2.x, I'll do that for the others too, soon...

I'd say on the next 2 months we'll know if we have solid recommendations of
new success criteria for WCAG next. There are no guarantees that we will be
successful formulating Success Criteria that are capable of the stringent
requirements. But we should know soon. The group begins reviewing our
mobile success criteria April 26 I think... let's see if it works...

On Sat, Apr 9, 2016 at 12:15 AM, John Foliot <john.foliot@deque.com> wrote:

> 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
>