Do WCAG/WAI need to considere feasibility ? #171
Comments
|
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.
<Personal Opinion>
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?
</Personal Opinion>
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
<#171>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c16T19yc0s4TD4rMdYjGspQlfnByks5ro6MRgaJpZM4MoF2X>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
|
|
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. |
|
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:
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. |
|
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. |
|
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. |
|
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.
|
|
@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 |
|
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
|
|
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.
|
|
+1 to Jonathan's response.
|
|
Reviewed by @steverep - comments on https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0005.html - Closing as editors draft has evolved. |
|
"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 |
|
Thanks @goetsu - I suggest that if that is the case, you log a fresh issue and clearly outline your proposal, thanks. |
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 :
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.
The text was updated successfully, but these errors were encountered: