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

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
<http://isolani.co.uk/articles/accessibilityOfTextOnlyWebsites.html>, or
rendered using tools such as BBC's BESTIE <http://betsie.sourceforge.net/>.
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> 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 <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Fri, 26 Jan 2018 22:47:36 +0200 * Abma<Jake.Abma@ing.nl
> <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]
> Sent: vrijdag 26 januari 2018 20:38
> To: Katie Haritos-Shea <ryladog@gmail.com>; Andrew Kirkpatrick <
> akirkpat@adobe.com>
> Cc: WCAG <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 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

Advancing the mission of digital accessibility and inclusion