Changing the level of SC 2.4.7 in WCAG 2.2 #1041
Comments
|
Hi @WilcoFiers so what would be a "better" approach working in this case according to you? Just to have both at AA? Personally I won't mind, but wonder what other people might have to say / views they have about such a suggestion, if they don't agree. What would be / where is the description that it needs to be successively ordered? In my opinion the (original) reason for 2.4.7. to be at AA is still valid so adding another SC does not automatically needs to force another SC to A. |
|
@jake-abma That's my thinking too. Leave 2.4.7 at level AA, and just add 2.4.11 in, also at level AA. |
|
Hi All,
After revisiting this problem, I'm with Wilco for all of the reasons he
stated, and I'll add a few more thoughts:
- While I often half-seriously/half-jokingly speak of WCAG 2.3, 2.4, and
2.5 the reality is we *ARE* pushing towards a new framework (WCAG 3.0)
where A, AA, and AAA classifications are being dropped. So I'm now starting
to think that worrying about A levels is something of a minor consideration
at this time: we need to still apply them as that is the framework of the
2.x releases, but their overall impact in 2020 and going forward is of
questionable (and I will argue diminishing) value.
- For all practical purposes, organizations that are applying WCAG to
their efforts are often driven by legislated mandates (be honest), and for
those actors, they are mandated to meeting both A and AA success criteria
by law, and so for them, the distinction is mute: they have to do them all,
so (they say) what's the difference?
- The survey [1] around this proposal was, as I review it today,
incomplete: it did not offer a fourth option of simply adding the new SC at
AA, while leaving 2.4.7 at AA. While this may have been debated and decided
on calls previously, it none-the-less seems that at a minimum that option
should have also been added to the survey when it was issued. Yes, I did
vote for the current proposed option, but I regret that vote now after
speaking with Wilco internally at Deque.
Given these concerns and considerations, I would like to ask that the
Working Group re-visit this decision. I'd prefer that it *NOT* block the
FPWD publication (or target date), but we also include an Editor's Note
that the decision of adjusting the AA classification to A is still under
discussion, and that feedback is being solicited by a wider feedback
mechanism (the FPWD publication). That is, after all, the reason for the
FPWD in the first place - wider review. So I propose we not lock in this
decision too firmly at this time, and gather more public feedback by
explicitly adding that Editor's Note.
Chairs?
JF
[1] https://www.w3.org/2002/09/wbs/35422/updating-wcag2-requirements/results
…On Fri, Feb 7, 2020 at 7:25 AM Wilco Fiers ***@***.***> wrote:
@jake-abma <https://github.com/jake-abma> That's my thinking too. Leave
2.4.7 at level AA, and just add 2.4.11 in, also at level AA.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1041?email_source=notifications&email_token=AAJL443WYFA7HRRUA6PYK4LRBVOL5A5CNFSM4KRNTKPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELC4T2A#issuecomment-583387624>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJL44Y4GDVAOY2KMWSFKCTRBVOL5ANCNFSM4KRNTKPA>
.
--
*John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com
|
|
I am also not in favour of changing existing SCs (nor their levels), but I wonder if the new focus criterion could not be given Level A? This would render 2.4.7 obsolete, but it would not set a precedent. The requirement in SC 2.4.8 that no horizontal scrolling is required at 200% (Level AAA) is also obsolete by SC 1.4.10: No scrolling at 400% (Level AA) |
|
I can't speak to the working group processes, but will state that I do not see changing 2.4.7 to Level A as being a notable concern for the many clients WebAIM works with or in our evaluation/reporting tooling. I believe the driving factor in this decision should not only be corporate interests and backward compatibility (as have been the only arguments here), but primarily accessibility for individuals with disabilities and the very conditions and factors for conformance levels that WCAG itself defines - https://www.w3.org/WAI/WCAG21/Understanding/conformance#levels Namely... Condition 1 - It must be "an important access issue". There's no doubt that non-visible focus indicators result in significant accessibility issues for numerous users. It's difficult to argue that any other AA or AAA SC is nearly as impactful as 2.4.7. Condition 2 - It must be testable. Visible focus indicators are readily testable - though typically require vision to test (not unlike several other SC). Factor 1 - "Whether the Success Criterion is essential". Keyboard navigation without focus indicators is nearly impossible without custom settings or extensions to override outline styles. Factor 2 - "Whether it is possible to satisfy the Success Criterion". Nearly all web content passes this SC by default. Specific styles must be implemented to cause it to fail. Factor 3 - "Whether the SC requires skills that could reasonably be achieved by the content creators". As above, the author must specify CSS to inhibit focus indicators, so by definition can reasonably remove or modify said styles. Factor 4 - "Whether the Success Criterion would impose limits" on look/feel/functionality. One could perhaps argue that default focus indicators may not align with look/feel desires, but these can readily be styled to taste. The loss of critical functionality by hiding them greatly outweighs these aesthetic interests. Factor 5 - "Whether there are no workarounds if the Success Criterion is not met". Workarounds for end users are available, but typically not reasonable for most users to either understand or implement. If these are indeed the determinants and factors for consideration in SC levels, to me, these very strongly support moving 2.4.7 to Level A. |
|
Would it make sense to change it to A while users are using a keyboard and AA while users are clicking with a mouse? I know there are many sites that monitor for tab/arrow key usage and mouse clicks to change focus styles accordingly. |
that's not how WCAG works...you can't decide on a level based on a specific user type |
|
My guess was that since it could be overwritten with user CSS by the user and that default browser focus was often used 12 years ago it ended up as Level AA. Today it's harder to overwrite with user stylesheets and most sites today turn off the default focus indicator. |
|
@JAWS-test 1.4.8 is not obsolete as it covers several other items in addition to horizontal scrolling. |
|
There are other considerations that make moving 2.4.7 to A level a very very bad idea, in addition to all the points that Wilco and others have made above. In the US, Section 508 documentation, starting with Access Board's website access-board.gov itself, has references to 2.4.7 [AA] which will become out of date. (Goodness, they haven't even got to taking WCAG 2.1 on board yet and we're already asking them to change things for 2.2!) The European EN301549 legislation will be put out of date, and all the legislation and/or documentation in all the member countries. And in Australia. And Canada, China, India and...[etc]. Think of the sheer amount of work, the meetings and discussions, the arguments, agonising and heartache that will be caused around the world as people and managements in the accessibility and development industries try to decide what steps to take as a result of this one character change. This isn't just a minor change of wording at W3C, it will tie up countless millions of people in fruitless discussions, using energies and resources that would be better put to furthering accessibility aims, and remediating websites that will still have no focus indicator regardless of whether it has one or two 'A's against it! Online forums, teaching establishments, lecturers, accessibility authors, all will feel compelled to spend time commenting on it simply because it has happened. And the only upshot of it all will be a loss of confidence in the A/AA classification, loss of confidence in the "WCAG 2.0 is not changed" mantra, and a consequent loss of confidence in the WCAG itself. The WCAG has inspired huge confidence around the world. Don't endanger that. And honestly, who cares? No one aims for just Level A compliance. In nearly 100 audits I have only once ever been asked to do a Level A audit, and that went away when I pointed out that it wasn't enough for full compliance with the law. As John said above, most website owners "are mandated to meeting both A and AA success criteria by law". So I would recommend dropping it. Don't even ask for more public feedback. I don't mean to be undemocratic in saying that, I just want to avoid world wide impact on millions of people just because of such a very minor change like this that achieves nothing. When even one of the originator's of the idea is now convinced it was bad, it's time to drop it! A solution? Have both 2.4.7 and the new criterion at Level AA, and add a few lines in the new criterion's Understanding document to explain why they are both at the same level and that the new one now improves on the old, but does not invalidate it. A little green note could be added to 2.4.7 as well. Much easier all round, and much clearer! |
@patrickhlauke I see your point, but would you mind explaining how is that different from 1.4.3 vs 1.4.6 where one criteria meets the needs of a specific type of user? There are other examples of similar criteria with different levels depending on user's needs. I was thinking along those lines when I made this suggestion. |
|
@gilluminate your wording seemed to suggest you wanted an SC that "morphs" levels depending on what the user is using. are you proposing a new SC specifically for one modality, at one level, and another SC that covers exactly the same, for another modality, at another level? that sounds exceedingly "bitty" |
|
@patrickhlauke yes, correct. That is what I'm asking whether it makes sense. Sounds like you don't think it does. |
|
I also think it's wroth pointing out there's some precedence for not changing the level of an CS when a new, stricter one is added. When 1.4.10 Reflow was added to WCAG 2.1, AG did not move 1.4.4 to level A, even though 1.4.10 almost entirely supersedes 1.4.4. I'm not opposed to this because it would create extra work for industry here. Honestly, just from a product owner's perspective, it doesn't matter. I would just leave it at level AA, because 99% of my user either won't notice or won't care. The part of me that's bothered by this the part that's been advocating for organisations to improve consistency of test methods for over 6 years. I think this will create greater division on how we report, which is something I think we should avoid. |
|
Given that we are re-hashing a discussion from last year, a quick summary of that discussion seems appropriate:
@WilcoFiers wrote:
As discussed before, not in the agreed sense that passing WCAG 2.2 would also pass 2.1. It does potentially raise compatibility issues for tools, but we have to balance that with the understandability. @johnfoliot, you made two points that are basically: 'what does it matter?', which is fairly easy to turn around to: What does changing it matter then? The other point was:
That option wasn't included because no one (apart from me in the very first post) suggested it or mentioned it as a good idea. Also see Michael's point above about the structure which you agreed with at the time. @guyhickling wrote:
Section 508 only (relatively) recently updated to 2.0, I assume it will jump onto whatever version is current the next time it gets updated. I'd also point out that @bruce-usab is very close to that process, and he favored the approach taken (see the last survey link). Wilco also wrote:
I don't see that as the same requirement, which is why 1.4.4 is still useful for when authors shrink text as you zoom in.
How about reporting 2.4.7 as level A if WCAG 2.2 is included, and otherwise reporting it as level AA? That could be transparent to the user, and any additional info for 2.4.7 could note the level is different for different versions. In the 2.2 draft 2.4.7 is marked as 'Changed', and more importantly the blog will include something like:
Lastly, if it seems I'm arguing strongly for the current approach, it was actually my least favoured option (as is apparent from the survey & minutes). However, we went through this last year and I'm struggling to see new information or something that has changed? In any case we will come back to this issue as a group when we also have public feedback on the FPWD. I've tagged the issue as such... |
Just picking this one aspect up: I believe the clunkiness isn't in how it's presented to the user, but rather that it forces a big rearchitecture behind the scenes for many tools. Assuming that many tools have some database-type structure that keeps a list of all SCs, and one of the fields for each entry will be "Level", as well as "WCAG version". Due to the "additive" nature of WCAG 2.1 (where 2.0 SCs were unchanged), it was nice and clean and allowed to have only one entry per SC. With this change, it will mean that at the very least each SC will need to have more complex fields to indicate which level it has depending on the WCAG version, and at worst tools now need to keep an entirely different set of SCs for each level - all due to that single SC that is changing from AA to A (so for 2.2. the set is exactly the same with only one SC actually different). |
Could well be, I read Wilco's comments as being about what is presented to the user though. |
|
What Patrick says exactly describes the problem, for all tools and similar software. And when I mentioned Section 508 and EU legislation, I was trying to make exactly the same point regarding law makers - it forces a huge amount of work behind the scenes. This very minor change from AA to A puts all their documentation out of date wherever they mention which level the SCs are. That isn't something that can wait to the next refresh - and 508 is just one government, there are all the other countries as well. They all have to at least discuss the matter. Causing a load of trouble for the tool makers is bad enough. But we need government administrators all round the world to go on supporting the WCAG. If we cause trouble for them by allowing this change, they might even start wondering if their support is starting to be more trouble than it is worth! It will cause at least some loss of confidence in the WCAG- that was the concern of my comment. |
|
@mraccess77 wrote:
This comports with my recollection, and provides sufficient rational for elevating 2.4.7 to Single A. @guyhickling wrote:
The Access Board will not be taking up 2.1/2.2/2.3/3.0 anytime soon. It is my professional opinion that 2.x should be improved as much as humanly possible in the meantime. Actually, the more demonstrable improvements between 2.2 and 2.0, the more pressure that there will be on us to update the 508 incorporation by reference. @jared-w-smith goes into some detail with his post. I don’t find anyone refuting the points of his argument. |
|
I'm good with keeping 2.4.7 at Level AA to support backwards compatibility and tooling, etc. Given that almost every policy is focused on A and AA I don't think the levels make as much a difference as they once might have. |
I think a much better question is; what has changed since WCAG 2.0, that requires us to change the conformance level on this SC? |
|
^ @WilcoFiers — see Jonathan’s comment above. I would also point people to the WCAG 2.x Priority levels discussion and the patterns for which SC landed at A versus AA. As a requirement that is Essential and Easy but not Invisible, 2.4.7 fits with either grouping. @mraccess77 wrote:
We have historically given all due consideration to the the A versus AA distinction. I don’t think 508 settling on Level AA is much of a reason to give that up! I would argue that the level designations continue to be very helpful for setting remediation priorities. This SC is a good example of that. Correcting for 2.4.7 should be at the top of the list after addressing single A failures and before addressing double A failures. |
|
Out of the nine people who have expressed a firm opinion, in this thread and if I've counted right, on whether the SC should change to Level A or not, 8 were against the idea. Some saw serious disadvantages to it. Yet the latest Editor's draft shows that it is going ahead anyway. I understand the question went to survey. Who were in the survey and how many people did it include, and has it been completed? I find it strange that such a survey should arrive at a contrary decision when 8 out of 9 people, all expert in the accessibility field, were against the idea to a greater or lesser extent! Is there a reason for this? |
|
Hi Guy, the history is all above in this comment. I can only see three people arguing against the change, the rest seem neutral or were having side discussions. Anyway, once we've approved (or not) the other SCs for the working draft, we'll circle back to this topic and tackle the comments on this SC. |
|
@guyhickling WG decisions are made based on consensus, and that is based on surveys and discussion on WG calls, and there there is a call for consensus on the working group list. The chairs determined that the call was successful, even though it wasn't unanimous. There were some concerns that were raised late in the CFC (and raised again here by Wilco ahead of the FPWD) but the chairs found that there was still consensus to put this into the draft as it was written in the proposal. So now, the FPWD is out and available for public comment, and this discussion can be considered as input along with other comment on this. Related, and I see that Alastair is looking at the "8 of 9" claim too, but as a former chair I can tell you that we aren't going to count how many people pile on to support or speak against something in a github issue - at least not directly. Of course, it doesn't count for nothing, but we also get +1's during meetings when people are discussing different ideas, and in surveys, and in emails. The chairs need to get clear information about pros and cons so that we can evaluate new information that the working group has not considered yet. If this is something that you feel passionately about, I encourage you to make an issue dedicated to your view on it. |
|
Hi everyone, We discussed this in the meeting: https://www.w3.org/2020/06/09-ag-minutes.html#item03 It seems that people have come around to it being backwards compatible, and we resolved to maintain the current levels shown in the first draft of 2.2, i.e. moving 2.4.7 to level A. |
In this public discussion, in this issue #1041 we have, between us, expressed a number of very serious objections to changing the the level of this SC. But when you read the above minutes, the comments made here have been completely ignored. Not discussed and reasonably refuted - just no one in the meeting saw fit to mention any of the objections raised here at all. This begs the question, what point is there in putting the WCAG 2.2. changes out for public comment, if no one within the WG is going to listen to the views expressed or allow their deliberations to take the public comments into account? In the WCAG 2.1 work in 2017/18 we had very successful discussions on the public side, with constructive discussion with the people actually creating the new success criteria, and the public comments were able to influence and achieve many improvements in the 2.1 additions as a result. I am beginning to wonder if (and not just on this thread and SC2.4.7 change alone) the process of putting things out to public comment has, in the 2.2 project, become a mere formality and nothing actually changes? It seems to have been admirably put by @awkawk above: "as a former chair I can tell you that we aren't going to count how many people pile on to support or speak against something in a github issue". Seems like we are all wasting our time then, are we? |
|
@guyhickling Also on the call we learned that the original commenter doesn't believe that this is a problem any more. The working group discussed a number of options and ideas, more than can be fully reflected in the minutes, which are not verbatim, so I don't think that the thoughts and comments shared were ignore, or without point, but it seems that the Working Group and the original commenter disagreed. I will also say that I feel that you've taken my point out of context in order to suggest that the Working Group doesn't listen to people, and I take issue with that. I believed then and still believe that if a good point is made by one person that the Working Group will listen and respond, and even if a point is agreed on by 3 people (which is how many I count in this GitHub issue) it is entirely possible that the WG will evaluate the information and come to a different conclusion. The Working Group will look at what 1, 3 or 15 people are saying and make a judgement as to whether it has merit. For your key point, which seems to be that this change would put 508/EN 301549 and any other policy that adopts WCAG out of date. The Working Group felt (in my opinion) that since this change would ONLY impact WCAG 2.2 that it doesn't have any bearing on 508 or EN 301 549 until such time as WCAG 2.2 is adopted. |
|
Hi Guy, It isn't a waste of time at all. We need to make a decision on how this would work in WCAG 2.2, various points have been raised, but after that discussion (in fact, multiple hours worth when you consider the discussion from last time as well), a decision was made. This decision is based on a consensus, i.e. it was the option the most people could live with. Colloquially, that doesn't mean everyone is happy, it means the least number of people are unhappy. I'm sorry you are in the latter camp in this case, but it doesn't meant the process is not working. The contributions the public can make haven't changed at all since 2.1. The difference this time is that, based on feedback of the 2.1 process from W3C members (outside the AG) & the public, we made sure the associated document like Understanding and Techniques were included by the time it went to public review. The SCs are a little more baked and coming through more slowly, but the rest of the process is the same. One of the reasons it wasn't a long discussion this time is that some of the group changed their mind, including people on this thread. Looking back at your points from above:
And again, I'm going to point out this wasn't my favoured option, I'm just working to make progress. |
|
oops, wrong thread |
and others
For the first public working draft of WCAG 2.2, it was proposed to change the level of success criterion 2.4.7 Focus Visible from level AA to level A. Presumably this was done to create space for a new success criterion Focus Visible (Enhanced), which would be at level AA.
My main concern with it is that this breaks backward compatibility of WCAG 2. While doing a dot-release (2.x), there is an implied promise that things are being added, but nothing gets changed that could potential break something. Changing the conformance level of a success criterion breaks things.
For some examples, most tools and reporters use conformance levels to filter results, or that report the conformance level along side the success criterion. Every tool and reporter that needs to support both WCAG 2.1 and WCAG 2.2 will be force to have to make a very clunky decision;
None of those are great options. I would think option 1 is the most likely. Everyone will just change the level of 2.4.7 in their product / training / whatever, and accept that they'll misrepresent WCAG 2.0 and 2.1. Practically, that then becomes an unofficial errata.
This change pushes industry towards an unofficial errata of WCAG 2.0 and 2.1. That's obviously not the end of the world, but it chips away at the integrity of WCAG 2 as a whole, and it just isn't necessary. Very few people care about whether or not something is level A or AA. That's why industry probably won't bother with option 2 or 3. Unfortunately, some will, and now anomalies start showing up when we compare audit results from different organisations. People are going to spend hours and hours trying to figure this out, and it's entirely preventable.
What concerns me most is that if a change like that is OK, what other changes can be made to WCAG 2.2, or 2.3, or 2.4. At what point do version numbers stop mattering and should we just treat each new release of WCAG as an entirely new thing. This change sets a bad president in my opinion, for a marginal improvement to the standard.
The text was updated successfully, but these errors were encountered: