search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.13k stars 257 forks source link

Clarify if modal dialog on page load is a failure of SC 3.2.1 + 3.2.5 #538

Closed JamesCatt closed 5 years ago

JamesCatt commented 5 years ago

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.

detlevhfischer commented 5 years ago

I have drafted a Working Group response (see mailing list).

JamesCatt commented 5 years ago

@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)

detlevhfischer commented 5 years ago

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 notifications@github.com:

@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.

alastc commented 5 years ago

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 https://github.com/w3c/wcag/issues/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.

JamesCatt commented 5 years ago

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:

Many thanks for taking this up, and personally I don't think there's any need for an apology.

I absolutely agree that unexpected modal dialogues can be a problem (and must be used judiciously), but I just wanted to flesh out the valid use cases for modal dialogues to help inform the Working Group's discussion. Consider the following scenarios:

  • Upon logging in, a user must be notified of a critical issue (i.e., a security problem, updated legal terms, etc). This could require immediate acknowledgement (for legal reasons) and/or action (for security purposes) before the user can be allowed to proceed.
  • A product browser opens detailed information for each product in a modal dialog instead of a separate document. Each product has its own URL for direct linking (and the modal opens immediately upon opening that URL).
  • Users must be notified of a potential health & safety issue. I once had to do a modal dialogue on page load because the site's organization was in a location prone to certain natural disasters and occasionally needed a means to warn people not to visit due to increased risk.

It's certainly true that these scenarios could be addressed through a different design pattern, but this may not always be technically feasible, and may not even be an improvement for accessibility. For example, redirecting the user to a different page upon logging in could address the first scenario, but I suspect it would be potentially more confusing than using a dialog--at least with the dialog, the page title would still be what's expected (and hopefully it would be clear what's happening as long as the dialog is implemented properly).

Thanks again!

jake-abma commented 5 years ago

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 (https://github.com/w3c/wcag/issues/170#issuecomment-202937912) 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: https://github.com/w3c/wcag/issues/538#issuecomment-456133087, 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 (https://github.com/w3c/wcag/issues/170#issuecomment-202937912) 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.

JamesCatt commented 5 years ago

@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.

innoticFR commented 2 years ago

Hello @alastc ,

I see that 3.2.1 was removed in F52 (https://github.com/w3c/wcag/pull/590) but the title is still "Failure of Success Criterion 3.2.1 and 3.2.5 due to opening a new window as soon as a new page is loaded" could you confirm that this is a mistake?

EDIT: sorry just saw that a ticket has already been opened https://github.com/w3c/wcag/issues/1262