-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify if modal dialog on page load is a failure of SC 3.2.1 + 3.2.5 #538
Comments
I have drafted a Working Group response (see mailing list). |
@detlevhfischer Thanks! I looked at the mailing list and saw in the meeting minutes from Jan 15 that you took this on, but I don't see the response you drafted in the list archives. Is this because it needs to be discussed by the group first? (sorry I'm not familiar with the working group's process) |
Sorry, it might be that I accidentally sent this to the list from the wrong email address, which was rejected - will check later. I wasn‘t quite sure myself whether the thing to do was to post this straight into the github issue, that‘s why I sent it to the list.
Sent from phone
… Am 16.01.2019 um 21:16 schrieb JamesCatt ***@***.***>:
@detlevhfischer Thanks! I looked the mailing list and saw in the meeting minutes from Jan 15 that you took this on, but I don't see the response you drafted in the list archives. Is this because it needs to be discussed by the group first?
(sorry I'm not familiar with the working group's process)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hi Detlev, you did send it, it went to the AG list on Thursday at 6:14am GMT, but I'll copy it here as well: We apologize for not yet having addressed this issue in our work for WCAG 2.1 as we had intended according to issue #170. Reviewing the situation, the problem seems to be that there is broad consensus that the opening of new windows as a result of loading a page is a significant accessibility issue that should be covered by WCAG. The absence of obvious other SC to tie this Failure to explains the reluctance to remove the reference to AA SC 3.2.1 On Focus, because without that, it would only be tied to a AAA SC, 3.2.5 Change on Request. The rationale of keeping this reference has been challenged since SC 3.2.1 is scoped to situations where context changes as a result of focus being set to a user interface element. Opening a new window does not do that, but instead sets focus to the page (which is not a user interface component). In terms of the effect on the user, the opening of a custom dialog as a result of loading a page can be as much a disorienting event as the opening of a new browser window . However, in the discussion of this issue, it has been pointed out that there may be valid use cases for opening a custom dialog and setting focus to it which should not be considered a Failure. As it stands, a custom dialog is not technically a new window so it seems reasonable for now to apply a narrow interpretation to F52 and not include custom dialogs. The Working group will need to discuss the option of extending the text of F52 to bring automatically loading custom elements (and possibly new elements lke the native dialog element) into scope. One way forward might be to modify F52 to narrow its scope to situations where after opening a new window, focus is set to user interface components on that new window. This change would then justify its reference to 3.2.1 On Focus. Another option is define a new Success Criterion that would be a better home for F51. These substantive changes will need more Working Group discussion before agreement can be reached. In the meantime, the working group shall again discuss, and this time decide, on the removal of the reference to 3.2.1 On Focus to end the current uncertainty over this issue. |
Roger that. I sent a reply to the mailing list, but I'm not sure if it went through (it has to be approved by the list manager), so I'll post it here as well:
|
Official WG response, per Feb 26, 2019 call and survey: Reviewing the situation, the problem seems to be that there is broad consensus that the opening of new windows as a result of loading a page is a significant accessibility issue that should be covered by WCAG. The absence of obvious other SC to tie this Failure to explains the reluctance to remove the reference to AA SC 3.2.1 On Focus, because without that, it would only be tied to a AAA SC, 3.2.5 Change on Request. The rationale of keeping this reference has been challenged since SC 3.2.1 is scoped to situations where context changes as a result of focus being set to a user interface element. In terms of the effect on the user, the opening of a custom dialog as a result of loading a page can be as much a disorienting event as the opening of a new browser window. However, in the discussion of this issue, it has been pointed out that there may be valid use cases for opening a custom dialog and setting focus to it which should not be considered a Failure. Opening a new window does not do that, but instead sets focus to the page (which is not a user interface component). As there is more than one question to answer the response is therefore fourfold. Q1: Is a modal dialog opening immediately on page load a failure of SC 3.2.1? No, this is not a failure for 3.2.1. The reason for this is that "SC 3.2.1: On Focus" is about when a "user interface component" receives focus, and the same UIC subsequently initiates a change of context. Although at page load the default focus goes to the body element this is not a UIC as the definition is: "a part of the content that is perceived by users as a single control for a distinct function" (https://www.w3.org/TR/WCAG21/#dfn-user-interface-components) and the body element doesn't fit this description. When there's no focus at all upon page load (#170 (comment)) in a UA the case is even more clear. Q2: Is a modal dialog opening immediately on page load a failure of SC 3.2.5? The working group has decided that this is not a failure if this happens "immediately". As mentioned above and in the comment: #538 (comment), there may be valid use cases for opening a custom dialog and setting focus to it. The key term here though is "immediately" and what this constitutes. Two scenarios we can think of where immediately is not considered to be true are:
In terms of the effect on the user, the opening of the dialog after a delay is much more interrupting and disorienting than immediately as a change of context is applicable. Another interesting scenario is when a user reloads the page and other content is suddenly present (because, as example, the dialog is removed after reload) or there is no real page load (SPA, single page apps). These scenarios might be considered working on a future version of WCAG. Q3: Is F52 a failure for SC 3.2.1? Based on the text for F52 "A failure due to opening a new window as soon as a new page is loaded", the working group concludes that this is not a technique applicable to 3.2.1. The reason for this is that "SC 3.2.1: On Focus" is about when a "user interface component" receives focus, and the same UIC subsequently initiates a change of context. Although at page load the default focus goes to the body element this is not a UIC as the definition is: "a part of the content that is perceived by users as a single control for a distinct function" (https://www.w3.org/TR/WCAG21/#dfn-user-interface-components) and the body element doesn't fit this description. When there's no focus at all upon page load (#170 (comment)) in a UA the case is even more clear. This doesn't mean there are actual similar examples online this failure doesn't cover. Like a user already moved focus in a page before the page is fully loaded, focus is set on an element with JS or the auto focus element, or windows open after clicking a link in a Single Page App (same problem other technical approach) where the "new page loading" is never done (or simulated). One way forward might be to modify F52 to refine its scope to situations where after "loading new content" / initiating a change of context, focus is set to user interface components in a new window / dialog. This change would then justify a reference to 3.2.1 On Focus. Another option is define a new Success Criterion that would be a better home for F52. These substantive changes will need more Working Group discussion before agreement can be reached. Q4: Is a dialog also a "new window" as mentioned at F52? When we take the dialogue into consideration as it stands, a custom dialog is not technically a new window so it seems reasonable for now to apply a narrow interpretation to F52 and not include custom dialogs. The Working group will need to discuss the option of extending the text of F52 to bring automatically loading custom elements (and possibly new elements like the native dialog element) into scope. |
@jake-abma Thanks for taking this on. I completely agree with everything in the proposed answer. Just wanted to mention one potential hiccup with the "slight delay" concept. If a modal is set to open immediately on page load in javascript, there could still be the potential for it to be delayed by a few seconds due to poor performance, no? This could be the fault of the author (loading too many ad scripts, for example), but it could also be because the user is on a slow device, or has too many applications running, or a combination of all of these factors. |
I'm trying to understand if having a modal dialog open immediately on page load constitutes a failure of SC 3.2.1 and/or 3.2.5.
Both SCs list F52 (opening a new window on page load) as a failure. Although "window" is not specifically defined in F52, the code examples both demonstrate opening new browser windows via javascript (
window.open
).So it would seem that F52 does not include modal dialogs, but a modal does seem to fit the definition of "change of context" since it involves a change of focus.
To muddy the waters even more, F52 is listed as a failure for SC 3.2.1 for some reason, even though it does not involve focusing a component (see #170 ). I understand this issue has been raised previously, and initially there was consensus to remove F52 from 3.2.1, but then once the PR (#175 ) was submitted the working group reversed course and decided against the change.
According to posts in #170 it sounds like all of this was supposed to be addressed as part of 2,1, but it seems like that didn't happen.
The text was updated successfully, but these errors were encountered: