Re: Transition UPDATED WCAG 2.1 Editor's Draft to Candidate Recommendation

I agree that we need a specification that can address requirements which don’t readily fit into the WCAG 2.x framework. I also agree that process requirements (which, as Gregg Vanderheiden noted, often cannot be verified without the cooperation of the implementer) should be among them.

There are various ways of designing a conformance scheme capable of including each of these elements. Based on discussions at TPAC last year, I think the Silver process is appropriately examining the possibilities.

I would also point out that WCAG and its successors are only one vehicle for achieving progress in Web accessibility – and often, not the best or most appropriate avenue, especially for technologies in the early stages of development, such as those associated with the COGA Task Force currently.

From: Alastair Campbell <acampbell@nomensa.com>
Date: Sunday, January 28, 2018 at 16:28
To: John Foliot <john.foliot@deque.com>, "lisa.seeman" <lisa.seeman@zoho.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: RE: Transition UPDATED WCAG 2.1 Editor's Draft to Candidate Recommendation
Resent-From: <w3c-wai-gl@w3.org>
Resent-Date: Sunday, January 28, 2018 at 16:26

HI John, Lisa,

I can see both sides, but to me it comes down to what the guidelines are (now).

From the user requirements, it has been a struggle to find a fit with *content* guidelines.

I think there are some more than could fit into 2.2, with work.

However, there are many that simply do not fit into content guidelines, either because they are best addressed in the process (e.g. with usability testing), or need to be applied ‘when appropriate’.

I see two useful streams of work:

  1.  The WCAG 2.x stream, working on the ones that do fit into content oriented guidelines.


  2.  Creating a WCAG ‘extra’ doc, not sure what to call it, but it would define the other things websites should do to enable people with disabilities. Unconstrained by the current criteria, it would be able to address process & appropriateness. I would also hope this bridges to AG 3.0, which needs to address process.

WCAG 2.0 has been so successful at least in part because of its strict SC requirements, so undermining it does not seem like a good idea.

Therefore addressing some of the COGA issues needs to be in a different framework, not an AAA or AAAA, or a straight extension. It needs to have different types of criteria.

If we stop trying to pound square pegs into round holes, perhaps it will get easier?

-Alastair


From: John Foliot

Hi Lisa,

While I can understand your frustration with the slow rate of progress, I personally don't think segregating or otherwise creating a new, "special" category of users with disabilities in our Guidelines will achieve anything positive: you are, quite literally, saying "do this for the majority of PwD, and do this extra stuff for a specific sub-section of that population". I was opposed to that type of thinking when this WG was contemplating "extension specs", and I remain equally opposed to that idea today.

I see that as the fastest way of ensuring that *nobody* will do the extra level of work you are seeking, because it's <quote>...ONLY for people with cognitive issues - that's why they split it out...</quote>, and when we look at the extra level of work required, and factor in "undue burden" issues, well, it simply won't happen. Heck, by doing this, even legislators (or, more importantly, the lobbyists who whisper in the government's ear daily) will have an excuse to not include those SC into legislation - you've helpfully split them out already.

I've previously worked in institutions where they already presumed that a specific level of education (not the correct measure of cognitive acuity, but one used frequently if mistakenly) precluded them from doing things for the COGA group: once at a University (presumes education level = lack of COGA issues) and a major bank (presumes that a certain educational level coupled with age of majority required to manage your finances = lack of COGA issues). I know they were wrong, you know they were wrong, but singling out those users doesn't make things easier, it makes it harder to gain traction (i.e.you will hear arguments like "You need to have a certain level of cognitive ability to do your finances, so these 'special' COGA SC aren't for us..."). Ensuring that "COGA-based" SC are 'equal' SC inside of WCAG strengthens them, *BECAUSE* we aren't making distinctions between user-groups.

You are proposing a divide-and-conquer scenario that I truly do not believe will benefit the constituency you want to benefit. Don't just take my word for it however, we've been down a similar path in the past: in the early 2000's we had 'separate but equal' text-only sites, either deliberately constructed that way<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fisolani.co.uk%2Farticles%2FaccessibilityOfTextOnlyWebsites.html&data=02%7C01%7Cjjwhite%40ets.org%7C7d511dec19a847b3b05208d566960221%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636527716832726245&sdata=CjAYvd9dAzBlwpn3OK8c3OhL9NtvmlHWargnxFCs%2FnQ%3D&reserved=0>, or rendered using tools such as BBC's BESTIE<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbetsie.sourceforge.net%2F&data=02%7C01%7Cjjwhite%40ets.org%7C7d511dec19a847b3b05208d566960221%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636527716832726245&sdata=kiRbJyY3thr8jMYekHLPd6oqyWwYKY2MqSvBCmCvKdk%3D&reserved=0>. What we quickly learned was that using this separate but equal strategy resulted for those text-only sites that were "accessible" on Day One, very quickly fell into, if not dis-repair, certainly neglect, and those text-only sites rarely kept up with changes made at the "principal" site, benefitting nobody in the long run. Yet it appears this is the same exact strategy you want to evolve now for users with cognitive issues. I can't support that - those that fail to learn from their mistakes are doomed to repeat them.

We need to continue to see progress towards addressing the needs of COGA users, of that there is no doubt. I think that part of the problem is (was) that the COGA TF came forward with close to 40 proposed SC in the beginning. Sadly many of those proposals weren't much further developed than generally proposed ideals, with no real framework or concrete specifics around implementation or testability, and so a large number of those SC fell to the wayside early on, as collectively we tried to do too much all at once. We can and should look at how to avoid that for the next round (WCAG 2.2), but we also need to be collectively realistic that we're not going to get ALL of the 37 some-odd proposed COGA SC that didn't advance at this round in 2.2 either, and so I might suggest that the COGA TF identify 5 or 6 SC for the next round, and concentrate and focus on ensuring they get in next time. We need to avoid trying to eat the elephant in one sitting.

Hunkering down into a bunker mentality however isn't the right way forward (IMO), and I would strongly oppose any move in that direction by the Working Group.

JF

On Sun, Jan 28, 2018 at 10:43 AM, lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> wrote:
Unfortunately this will just continue the lack of equality between accommodation for different disabilities. Publishing more and more guidelines with unequal levels of accommodation for different disabilities   destroys our credibility and is, in my opinion, wrong.

Maybe we could change the grading system so that we add a AAAA level. Most of triple AAA would become level AAAA - IE a wonderful level of accessibility.
AAA would be essential accommodations in critical services - in other words, items that are really important for the user but may not be widely doable on all sites. Most coga criteria would come under that. At AAA user testing may be required. Or design changes may come into affect. Or there may be a big author burden. However it is always important for the user. We leave it to legislators to say when AAA is required.

Or we could go back to the extension model


All the best

Lisa Seeman

LinkedIn<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fil.linkedin.com%2Fin%2Flisaseeman%2F&data=02%7C01%7Cjjwhite%40ets.org%7C7d511dec19a847b3b05208d566960221%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636527716832726245&sdata=2ITpP9373Wi5IYVAErcnl6zNMR8WU9DPu4fs0p9x858%3D&reserved=0>, Twitter<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FSeemanLisa&data=02%7C01%7Cjjwhite%40ets.org%7C7d511dec19a847b3b05208d566960221%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636527716832726245&sdata=5bUkMO5Ns4farcVuapAvpvKvW7xUdgp2UHKf%2BAmXckU%3D&reserved=0>




---- On Fri, 26 Jan 2018 22:47:36 +0200 Abma<Jake.Abma@ing.nl<mailto:Jake.Abma@ing.nl>> wrote ----
It would be interesting to see where possibilities for change lie from within the W3C.
Personally I don't think more time is the key here, three years is way too long.

In the agile way of thinking you could change the model to allow for adaptation / iteration of SCs and release even more frequent than once in a year and a half. The biggest problem as I've experienced it is too much of a big chunk in too little time with too less people having focus on main issues (until it is too late).

You can also see it in another direction and narrowing it down to a max of two SCs per task force at a time where quality and focus is key so everyone can contribute to all new work and keep the overview for all what's happening. Releasing every 6/9 months and allow for bug fixing / iterations after release.


-----Original Message-----
From: Léonie Watson [mailto:tink@tink.uk<mailto:tink@tink.uk>]
Sent: vrijdag 26 januari 2018 20:38
To: Katie Haritos-Shea <ryladog@gmail.com<mailto:ryladog@gmail.com>>; Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>
Cc: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: CFC - Transition UPDATED WCAG 2.1 Editor's Draft to Candidate Recommendation

Thanks Katie. This was a thoughtful assessment of a prickly topic. A couple of thoughts inline...

On 26/01/2018 18:34, Katie Haritos-Shea wrote:
> I am shocked at all that we did not do because there was no time. As
> the global standard relied upon for the civil rights of millions of
> people are we really OK with privileging the schedule over the content?

I think the goal is to be able to move in a timely fashion, and have the right content. I don't think we got it right with 2.1.

We tried to move from a 10 year cycle to an 18 month cycle, but we didn't define a clear path beyond 2.1 (setting aside Silver for the moment).

For a regular release cycle to work, people have to have confidence that the next version will happen. That way if something needs a little more time to reach maturity, it can do so, because the next version will soon be there.

So we took the first step towards a regular release cycle, but didn't follow it through properly. This meant many people were stuck in the mindset that if something didn't make it into 2.1, it wouldn't make it at all.

[...]

>
> Does it need to take another 10 years to get it right? Absolutely not.
> And I said before, there are options between 18 months and 10 years. I
> suggested 3 years as a reasonable "iteration"  timeline for an
> international accessibility standard.
>

On reflection, I think three years might have been a better target for 2.1. It may well have been an easier transition for some people to make.

That said, had we not adopted this timeline, the EU would have legislated without any of the 2.1 SC at all.


Léonie.

--
@LeonieWatson @tink@toot.cafe<mailto:tink@toot.cafe> Carpe diem


-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
-----------------------------------------------------------------






--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion

________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________