F52 not a failure

[awkawk]

Name: chaals mccathie nevile
Email:
Affiliation: yandex
Document: TD
Item Number: F52 (https://www.w3.org/TR/WCAG20-TECHS/F52.html)
Part of Item: Applicability
Comment Type: technical
Summary of Issue: This incorrectly states a failure of 3.2.1
Comment (Including rationale for any proposed change):
Changing a document on load, i.e. before the user has focused anything, does not fail success criterion 3.2.1 as stated in this technique, since it does not occur as the result of a change in focus, but rather as the consequence of a request to activate a link.

Nor does it fail 3.2.5 since there is no timing implication, it is merely part of the synchronous loading of resources that occurs as a result of following a link.

Proposed Change:
Remove the technique from failure modes

[awkawk]

@chaals,
If the page is loaded then the focus is somewhere in the content. Are you saying that nothing is focused or that the loading of the new page happens before the loading of the first is completed?

[chaals]

Neither. The user didn't move their focus, the user followed a link. The focus was then put on something in a way the user may have observed, and then moved again, much like an autofocus.

This is highly implementation-dependent, but in general, it isn't the result of the user changing focus, it is the result of following a link, which means you intended to go somewhere else.

[awkawk]

But 3.2.1 doesn't require that the user set the focus, just that the focus is set:

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A)

I think that the failure is based on a page loading and the user being automatically pushed somewhere else right after the page loads, so the user may hear the title of the page and then suddenly starts hearing something else due to the focus being shifted to the new page content.

I can check with the group about this. At a minimum there is a need to update some understanding text if what I am saying is accurate and if you are correct then we will need to modify or remove the failure.

[Ryladog]

Like an ad on the page grabbing the focus when you land....

[chaals]

@Ryladog - exactly. Or a user survey request, or some latest news, or the thing that warns you this is an out-of-date version of something or asks you to pay before you get access.

@awkawk:

the failure is based on a page loading and the user being automatically
pushed somewhere else right after the page loads

That's not initiated by changing focus. Sure it's annoying if it isn't smooth, which might happen if there is a high network latency or really weird scripting, but it doesn't violate what the relevant success criteria state.

[awkawk]

@chaals:
The SC doesn't talk about the user changing focus, it talks about when the focus is received. This may include when a user clicks on a link to a page or opens a shortcut on their system to get to a web page - the focus is received by the page and if the page automatically changes the context then the failure is triggered. My take anyway...

[jnurthen]

Unless the user has already moved into the page, or the page focuses an element with JS or the auto focus element, or the load was triggered with a #idref url there is no focus in a page upon load.

[chaals]

@awkawk I think your read confuses coincidence and causality. It is possible that something on the page receiving the focus is what initiates the load of a popup or whatever. But in the case described, that's a pretty unusual way of doing it - because it performs badly and often doesn't work. The standard thing to do is run some function on Loaded or DOMContentLoaded that initiates the context setting.

There is a variant which is to make sure the user has engaged with the page a bit, but that's a different case.

[awkawk]

@chaals thinking about this more I'm in agreement that F52 isn't appropriate for 3.2.1. I'm not sure why it passes 3.2.5 though. It seems that there is a case to be made that following a link that results in a main window and 3 pop up ad windows (and moves the focus to the ad window) is changing the context unexpectedly unless the author indicates in advance for the user to know what they are getting into. If I click a link to go to "2016 mountain bikes" and it takes me to a page and there are a few popups (maybe the main page title gets read before the context changes, maybe not) and what I start reading on the page is ads for tire tubes then either my context was shifted unexpectedly or the link text (SC 2.4.4 / 2.4.9) is very wrong.

[lauracarlson]

Related discussion on the WebAIM list: Opening modal window without user action.

[joshueoconnor]

I think we need to revisit what 'change of focus' and 'change of context' mean and where it is isn't a failure (of this or other related SCs). Mega menus anyone?

[awkawk]

Resolution from the WG meeting April 5, 2016: "The WG generally agrees that F52 doesn't apply to 3.2.1 and needs someone to write up the official proposal of changes in GitHub".

https://www.w3.org/2016/04/05-wai-wcag-minutes.html#item06

Once the changes are written up (preferably in a pull request) then the WG can review and approve.

[alastc]

I posted to the list a long description of a few aspects for this issue, but the short version is:

I agree there is an issue, if a new window is opened on page load, then it can’t be a failure of 3.2.1 as that applies when a component has received focus. Wrong trigger mechanism.

I think 3.2.5 is still relevant though: "Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes."
And the understanding 3.2.5 doc explicitly calls out "automatic launching of new windows”.

The key factor for me is: Although the user has initiated a change (e.g. clicked a link), they did not know they were initiating one or more new windows as well.

If a user knew that a new window would open as well, then that would be ok. Therefore this failure could be for of 3.2.5 only, or for 3.2.5 and 2.4.4 (Link purpose).

I think it could be a failure for both independently. I.e. If you tell the user in the link text then it is not a failure of 2.4.4, but it would still be a fail (at AAA) of 3.2.5.

In practice I can’t see people using link text like “Mountain Bike selection (opens 3 advertising pop-ups)”, so I think most examples of this would be caught at the AA level.

So my recommendation is to drop 3.2.1 from F52, but add 2.4.4.

Part of that would be to add to the procedure to check whether the link that leads to the unexpected pop-ups includes information about them, which then affects what level the fail is at.

Unless it would be better to have two separate fails? One for each SC.

@awkawk I've not done a git update for WCAG, is it best to create a branch for the issue and push that up?

[awkawk]

@alastc - I am inclined to disagree to adding 2.4.4 to this as pages aren't always loaded as a result of following a link. One might follow a desktop shortcut, type a URL into the address bar, arrive at a page as a result of a properly-notified page redirect, or perhaps they clicked a button or submitted a form to make the new page load.

As a failure, we need to make sure that it is always a failure, so I don't think that adding 2.4.4 is advisable.

Regarding a pull request, you should work off of the Q3 working branch, and submit a pull request off of your fork of that branch.

[alastc]

Ok, the safe change for the moment is to remove the 3.2.1 references, I'll do that first.

[awkawk]

On the April 5 call the WG generally agreed that F52 doesn't apply to 3.2.1 and needs someone to write up the official proposal of changes in GitHub. (https://www.w3.org/2016/04/05-wai-wcag-minutes.html#item06)

@alastc has taken that task on (#175).

[DavidMacDonald]

Proposed Response:

The working group was not able to come to consensus on removing this failure. It was agreed that F52 addresses is a genuine accessibility issue. We also agree that the mapping is somewhat ambiguous. However, the failure was created as a result of consensus by the previous working group and has been in effect for 8 years without objection. The group will be reviewing this failure in the next version 2.1 and we will provide more granular advice regarding modal dialogue boxes, popups, and changes of context in the next version of WCAG which is currently under development and which will further address the complexities of dynamic environments.

[chaals]

This seems like an incorrect decision.

The fact that something fixes an accessibility problem is insufficient to claim it is therefore required by a given guideline.

If the set of guidelines does not identify a particular problem, then fixing the guidelines seems reasonable. Claiming that a guideline makes some requirement that it doesn't state is unreasonable, especially in a normative document.

I therefore object to this resolution.

[alastc]

The issue did seem to hit a deadend, I wasn't sure what to do with it.

I think F52 is still a valid failure for 3.2.5, but needs the references to 3.2.1 removing. Then as part of 2.1, doing what David said.

[JamesCatt]

Is there any chance of this issue being revisited? It sounds the like the argument in favor of keeping the status quo amounts to "it should fail something", which I agree with, but 3.2.5 seems like the appropriate venue for it. 3.2.1 really doesn't make much sense, especially when considering that it specifically refers to focusing a UI component, which is defined as

a part of the content that is perceived by users as a single control for a distinct function

Loading a new page would clearly not meet that definition, unless something like a button or input automatically receives focus on page load--and even then it doesn't seem that it should be a failure of 3.2.1 unless receiving focus is the actual trigger for opening the new window (if the two events were just coincidental, then the page would still fail under 3.2.5).

@DavidMacDonald could you clarify if this was, in fact, reviewed as part of 2.1, or what happened with the plan to offer guidance on modal dialogues? I've tried searching through the meeting transcripts but can't seem to find anything. The modal scenario in particular I think is important, given how common it is for sites to have a modal on page load.

[mraccess77]

At minimum I think we need to clarify that a dialog appearing on page load and taking immediate focus would not be a failure of 3.2.1 or 3.2.2.

[JamesCatt]

At minimum I think we need to clarify that a dialog appearing on page load and taking immediate focus would not be a failure of 3.2.1 or 3.2.2.

@mraccess77 To clarify, do you mean the official WG consensus is already that modals are not considered a failure (i.e., the docs just need to be clarified, but no changes to the spec are required)? Or do modals still need to be discussed/decided by the working group?

Sorry to be nitpicky. I have a few projects where the course of action depends on the answer to this.

[mraccess77]

It had been discussed previously but I’m not sure if we have an official record.

[jake-abma]

We need to consider that we also have modals with their own URL, like the modals activated by a Fab button where you perform a task. Google had those although I can't seem to find one anymore...

It may look like: https://www.site.nl/transfer#modal-id and when the page opens, the modal / task opens. This task can be saved as a bookmark to directly activate.

Although my personal opinion is that this is bad practice, wondering what others think.

[JamesCatt]

It had been discussed previously but I’m not sure if we have an official record.

@mraccess77 Ok, thanks for clarifying.

We need to consider that we also have modals with their own URL, like the modals activated by a Fab button where you perform a task. Google had those although I can't seem to find one anymore...

@jake-abma I believe they used to use this pattern for the Chrome Web Store—the info for each extension opened in a modal (with its own URL), rather than a separate page. Although it may not always be a good solution, I can see some valid use cases (i.e., a "quick view" for a product browser, where there isn't enough content to justify a whole other page).

In any case, you're right that forbidding modal on page load would effectively ban this design pattern.

[JamesCatt]

Is there any chance of getting this on the agenda for the working group to address (either removing F52 from SC 3.2.1 or clarifying whether or not it applies to modals as @mraccess77 suggested)?

I don't know what the process is for making that happen, but if there's anything I can do to help move this forward please just let me know.