Do WCAG/WAI need to considere feasibility ?

[goetsu]

Hi,

I just want to open a debate here.

First I want to make clear that I think most of new guidelines are perfectly logical in term of users needs. But I'm really concerned about WCAG 2.1 setting the bar way too high and way to fast in term of feasibility for dev / design / project manager. I mean vast majority of people are still struggling to implement basic WCAG 2.0 success criteria. From what I see in my professional activity, I'm 100% confident that some of the new level A and AA SC will :

• never be done even for some of my customer that are currently AA WCAG 2.0 compliant
• or will be done using "alternative version" because it has way to much impact on the "regular" design / content / code.

I know that WAI itself do not force anyone to implement WCAG but laws do (or try to) and will at some point enforce 2.1

Maybe we can't have a more progressive approach when level of new SC are chosen like setting them in AAA for 2.1, then AA in 2.2, and having a public roadmap clearly specifying that. This way, people will have time for discover, understand, teach and see how they can achieve them knowing that at some point they will have to do it.

Otherwise we can also have a more clear statement that WCAG 2.0 will not be replaced by 2.1 and that only 3.0 will be considered as a new version that replace 2.0.

[johnfoliot]

Hi Goetsu,

Otherwise we can also have a more clear statement that WCAG 2.0 will not be replaced by 2.1 and that only 3.0 will be considered as a new version that replace 2.0.

WCAG 2.0 *WILL* supersede (i.e. replace) WCAG 2.0 at the W3C as the most current Accessibility Guidance from the W3C once WCAG 2.1 is published. Whether or not countries and/or individual organizations will do the same at the same time we publish 2.1 will, of course, be left up to those countries and organizations to determine. Whether or not those entities will wait for "Silver" (aka 3.0) is a decision that *THEY* will make, not the W3C, although my suspicion is that most countries will likely choose that option. In that scenario, all of the new SC that advance during the WCAG 2.1 >> WCAG 2.2 >> (will there be a 2.3? who knows?) work effort will likely be looked at as "optional" from a legal/compliance perspective today/upon publication, BUT, they will also be the signal that entities should expect these to have a full-force-of-law status in different countries/territories "soon" - i.e. once those countries adopt the new(er) standard. That will provide the "window" of time you suggest will be needed when you state, "...time for discover, understand, teach and see how they can achieve..." Regarding "feasibility" (or as I am thinking of it, implementability at scale), I share some of your concerns as well, and as the Working Group reviews the proposed SC that have come forward (along with when we start to process feedback from the larger community), I for one will be watching that quite closely. Having many years of working with larger organizations, where the accessibility stakeholder is but one person around the table, I share your concern that if we try and impose *too* heavy a lift on content authors, they will simply ignore, or "refuse" to address individual SC. We've seen examples like that in the past, where the Government of Canada (for example) has explicitly exempted sites from: Complex maps (text alternatives) WCAG 2.0 Success Criterion 1.1.1 Non-text content Live Video Captions (closed captions) WCAG 2.0 Success Criterion 1.2.4 Captions (Live) Audio Description (prerecorded video) except where the video provides information related to health and safety of Canadians WCAG 2.0 Success Criterion 1.2.5 Audio Description (source: https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=23601#appB) Whether or not this is "fair", or if it still leaves some Canadians with inaccessible content is a real issue. But balanced against the time, cost and effort to meet these requirements, the Government of Canada ruled above. For this reason then, I think we as a larger group need to be metered in our requirements, and honestly come to a point where the needs of both content users AND content creators are met equitably and fairly, while still advancing our larger goal and mission. Personally, I am all for "shooting for the stars", as long as we all recognize that sometimes that may only get us to the moon, but hey!, getting to the moon is an accomplishment in its own right, right? JF On Fri, Mar 24, 2017 at 6:03 AM, goetsu wrote: > Hi, > > I just want to open a debate here. > > First I want to make clear that I think most of new guidelines are > perfectly logical in term of users needs. > But I'm really concerned about WCAG 2.1 setting the bar way too high and > way to fast in term of feasibility for dev / design / project manager. > I mean vast majority of people are still struggling to implement basic > WCAG 2.0 success criteria. > From what I see in my professional activity, I'm 100% confident that some > of the new level A and AA SC will : > > - never be done even for some of my customer that are currently AA > WCAG 2.0 compliant > - or will be done using "alternative version" because it has way to > much impact on the "regular" design / content / code. > > I know that WAI itself do not force anyone to implement WCAG but laws do > (or try to) and will at some point enforce 2.1 > > Maybe we can't have a more progressive approach when level of new SC are > chosen like setting them in AAA for 2.1, then AA in 2.2, and having a > public roadmap clearly specifying that. This way, people will have time for > discover, understand, teach and see how they can achieve them knowing that > at some point they will have to do it. > > Otherwise we can also have a more clear statement that WCAG 2.0 will not > be replaced by 2.1 and that only 3.0 will be considered as a new version > that replace 2.0. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > , or mute the thread > > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[FionaHolder]

I do agree. At risk of offending some of the people that have clearly worked very hard defining all the additional SC, it feels like because there has been so long since any new SC were considered, everyone is trying to add so much to this version its just not feasible for developers.

It's already very difficult to convince stakeholders to implement WCAG 2.0 without an explicit requirement from the client to do so. This will become hugely more difficult with WCAG 2.1 and I'm concerned that in an attempt to make WCAG better, fewer sites will actually bother with it at all, which is obviously worse.

[alastc]

The short answer (IMO) is yes, WCAG does need to consider feasibility as a key factor.

Just remember where WCAG 2.0 was in 2006, when I first looked at the draft I (insert expletive here) a brick. I'm not saying it's in the same state, but two things happened during the review process:

1. The SCs were refined to consider edge (and not-so edge) cases, and made more feasible by focusing them more on what really mattered.
2. The ways of fulfilling them became clearer and (to people outside the process) easier.

The 'understanding' and techniques have not been drafted yet (at least for the SCs I'm managing), that obviously needs to happen and it might allay some fears then.

However, the main things is that we need to identify the use-cases & scenarios which are reasonable and should not be covered (or should be covered when they are not).

Some of the SCs are plugging interface gaps/changes since 2008 and are fairly straightforward (e.g. contrast for graphics). Some are extending the concept of adaptation by users (e.g. linearisation & adapting text). Some overlap with usability fairly heavily (e.g. some of the COGA SCs).

Overall the new SCs should not add more of a burden than the 2.0 ones, apart from there just being more of them. Where you see undue burden without a solution, please do comment.

[DavidMacDonald]

I too am very concerned, that an overly ambitious WCAG2.1 will be like the 2nd and 3rd movies of the Matrix series. The first one was a hit, but unanimous public opinion is that the 2nd and 3rd were not.

Let's follow up WCAG 2.0 with a tight, testable, implementable, and helpful standard.

[FionaHolder]

I agree David. I don't feel that there are enough developers (not a11y specialists) participating in the discussions here to raise how much of a red flag this could be. Concerns are just being pushed back on the basis of how much disabled users need the changes, rather than whether they are feasible on a practical level.

Also, loads of the new ones are at A level, this would all be a lot more palatable if new ones were at AAA or even AA until the technical implementation kinks could be ironed out.

[WayneEDick]

I think there comes a point where we must decide. Do we want these to be accessibility guidelines or partial accessibility guidelines. If we do not add necessary features to support access for all major populations of disability then we have partial accessibility guidelines.

If we really decide on partial accessibility, then we should inform legislatures that these guidelines do not apply to the excluded populations. Our group just cannot figure out how to include these groups.

That would be OK because it would leave entities to come up with solutions seeing that W3C cannot do it. Claiming to offer accessibility guidelines, knowing that they do exclude populations, is just irresponsible.

Consider linearization. If we cannot formulate language to accomplish linearization with languages and platforms that can support it, that is OK. Just don't claim that a web page is accessible if it cannot support this. Just say we cannot figure out how to solve this critical accommodation issue. People with low vision won't be able to use pages, but we don't know how to fix it. Our framing of WCAG 2.0 was too narrow.

Don't tell people with disabilities that they don't know how to use AT correctly, or that multi column pages really are accessible, or that screen magnification is accessibility support. Be honest. We couldn't solve the problem.

[goetsu]

@WayneEDick that why I propose not to remove everything but to question and define level of success criteria with more concerne about complexity of implementation. Doing that entities could still decide to go for level AAA from the beginning or wait for this criteria to go in AA or A because they decide to only scope A criteria. At least they will know that level of success criteria is reflecting a mix between user need and complexity of implementation.

Other solution can be to add a new "complexity" attribute to success criteria different than level that will help people to choose SC they want to cover based on those two informations

[mraccess77]

Wayne, with all respect the WCAG and the WG has always been clear that implementing WCAG will not make content accessible to all users in all situations. If people have assumed otherwise that is an incorrect assumption on the part of that person whether it be a lawmaker, educator, developer, etc. I agree we should strive to make more content more accessible to more people – however there is a balance we must carefully weigh in order to make sure the guidelines are adopted.

From the WCAG 2 abstract:

Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general.

Best Regards,

Jonathan

Jonathan Avila Chief Accessibility Officer SSB BART Group

[WayneEDick]

This discussion has many levels. I will attempt to classify some of them.

1. Necessity - If an accommodation is essential to support web usage for a group of individuals
2. Platform of Accessibility - The WCAG 2.0 model of technology independence was an intersection model. It took the intersection of accessibility capabilities of all technologies and only considered those that were met by all. This is an assumption that can be changed for 2.1. If a technology X can support an essential accessibility feature using existing coding methods it is reasonable to require that support for authors using X. The fact that another technology Y cannot supply the necessary support should not set the author using X free from providing access with X. I would call this a union model. Namely, authors are responsible for providing all the semantic support that their technology supports.
3. Testability - Testability may not be binary all the time. We may need to rely on high probability tests. For example, if we devise a test that would reject a null hypothesis 90% of the time that would probably be good enough, but we could insist on 95% confidence.

WCAG 2.0 really did leave low vision and cognitive disabilities out. The task forces have proven that. Why did that happen? We must look at new SCs, but we must also look at the set of assumptions that lead to this serious omission. If we repeat all of the logic that let to the omission of major classes of disability, then we will probably come up with a system that omits them again.

[DavidMacDonald]

+1 to Jonathan's response.

[joshueoconnor]

Reviewed by @steverep - comments on https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0005.html - Closing as editors draft has evolved.

[goetsu]

"I also think the suggestion to move everything to AAA or declare 2.1 not an official version per the original comment is contradictory to our charter."

I never propose to move to AAA all SC but only the one where we are aware of major implementation difficulties and then move them to a lower level on future release 2.2, 2.3 etc and this question is still valid for the current FPWD

the question of a better consideration of implementation difficulties remains. I'm specially interested to have feedback on the proposal I maid to have a new "complexity" attribute to each success criteria different than SC level. This will help people to define accessibility regulation based on those two informations

[joshueoconnor]

Thanks @goetsu - I suggest that if that is the case, you log a fresh issue and clearly outline your proposal, thanks.