Update focus-not-obscured-minimum.html #3083
Conversation
Attempt to add an additional section on considerations
slight tweaks for nuances
more tweaks
| <section> | ||
| <h4>Modal dialogs versus overlays</h4> | ||
| <p>A properly constructed modal dialog will always pass this SC. Even if it appears directly on top of an item with focus, the dialog takes focus on appearance, and thus the item receiving focus -- the dialog or one of its components -- is visible. A properly constructed modal maintains that focus and prevents interaction outside the modal until it is dismissed.</p> | ||
| <p>A dialog-like overlay that does not take focus on appearance and does not either constrain interaction to the overlay or dismiss itself on loss of focus (thus allowing focus to exit into the content behind it) will be at risk of failing this SC, where it is positioned such that it can obscure other content.</p> |
There was a problem hiding this comment.
| <p>A dialog-like overlay that does not take focus on appearance and does not either constrain interaction to the overlay or dismiss itself on loss of focus (thus allowing focus to exit into the content behind it) will be at risk of failing this SC, where it is positioned such that it can obscure other content.</p> | |
| <p>A dialog-like overlay that does not take focus on appearance and does not either constrain interaction to the overlay or dismiss itself on loss of focus (thus allowing focus to exit into the content behind it) will be at risk of failing this SC, where it is positioned such that it can obscure other focusable items.</p> |
Section on openable persistent disclosures added.
|
|
||
| <ul> | ||
| <li><strong>When the additional content appears, it displaces existing content.</strong> An accordion is an example of this. When an accordion is opened, the disclosed content shifts existing content further down the page. Since the new content does not obscure existing content, it cannot obscure the item with focus.</li> | ||
| <li><strong>When the additional content appears, existing content reflows.</strong> The popout sidebar on the <a href="https://www.w3.org/TR/WCAG22/">WCAG standard</a> is an example of this pattern. When the side menu is activated, it discloses a new section of information along the left side of the page. The main content area is reduced horizontally to accommodate this, and the existing main content reflows to fit in the thinner space. As a result, there is no overlapping content between the two sections; the item receiving focus, whether in the left navigation or in the main content, will not be obscured by the other section.</li> |
There was a problem hiding this comment.
The popout sidebar on the <a href="https://www.w3.org/TR/WCAG22/">WCAG standard</a> is an example of this pattern. - are we so confident that the UX of this page won't change for the lifetime of this understanding document that we're comfortable having the text take a dependency on its behavior? Might be safer to omit the example.
There was a problem hiding this comment.
I'd like to have techniques that illustrate these. In the interim, especially when the SC is new, I think linking to a live site is useful.
| <li><strong>The disclosure expands into an area of the page containing no other content.</strong> Many pages are designed with wide margins, providing significant white space into which new content can be disclosed. Many chatbots and toasters are designed to 'slide up' into the right unpopulated side of a page. Where authors are careful to ensure content is not obscured at each breakpoint in a response design, no obscuring of other operable content need occur.</li> | ||
| <li><strong>When focus leaves the additional content, it is hidden or collapsed.</strong> This is very similar to patterns discussed next under Non-persistent disclosed information. A distinguishing factor can be that the user's last point of interaction in the disclosure is preserved (it persists) even though it may be hidden until a user returns. Some trees and left navigation pattterns behave this way. </li> | ||
| </ul> | ||
| <p>Where disclosed content persists and causes existing content to be obscured, it will be at risk of failing this criterion if it prevents users from seeing the focus indicator.</p> |
There was a problem hiding this comment.
what about disclosures that persist/overlay other content, and allow keyboard focus to leave the disclosure, but allow click and tap outside of the disclosure content, or esc key to dismiss the disclosure content at any point that it is open?
the persistent disclosure that traps focus but allows outside clicks is mentioned, but not this variant where outside clicks/taps or esc key would dismiss the overlaying disclosure.
There was a problem hiding this comment.
@scottaohara , I'd like to explore wording that mirrors some of the behaviour required in On Hover or Focus to try to allow for such an interaction mechanism. Something like:
Where content disclosed by the user can obscure other content, if the user can reveal the item with focus without moving keyboard focus (for example, by dismissing with Esc), such disclosed content is not considered to fully obscure the item receiving focus.
There was a problem hiding this comment.
i think that's on the right track. Thank you! That'd definitely alleviate my concerns if that sort of text was added
| <li><strong>The disclosure expands into an area of the page containing no other content.</strong> Many pages are designed with wide margins, providing significant white space into which new content can be disclosed. Many chatbots and toasters are designed to 'slide up' into the right unpopulated side of a page. Where authors are careful to ensure content is not obscured at each breakpoint in a response design, no obscuring of other operable content need occur.</li> | ||
| <li><strong>When focus leaves the additional content, it is hidden or collapsed.</strong> This is very similar to patterns discussed next under Non-persistent disclosed information. A distinguishing factor can be that the user's last point of interaction in the disclosure is preserved (it persists) even though it may be hidden until a user returns. Some trees and left navigation pattterns behave this way. </li> | ||
| </ul> | ||
| <p>Where disclosed content persists and causes existing content to be obscured, it will be at risk of failing this criterion if it prevents users from seeing the focus indicator.</p> | ||
| </section> | ||
| <section> | ||
| <h4>Non-persistent disclosed information</h4> |
There was a problem hiding this comment.
in the intro to this doc, non-persistent disclosures aren't mentioned, but get quite a bit written about them. maybe worth alluding to?
Typical types of content that can overlap focused items are sticky footers, sticky headers, and non-modal dialogs. As a user tabs through the page, these layers of content can obscure the item receiving focus, along with its focus indicator.
There was a problem hiding this comment.
I will attempt to incorporate this.
Added additional note to address comments by Scott Ohara in the PR #3083 (comment) and recent comments in the issue starting at #2751 (comment)
Modifying the language, but not meaning of the existing note, to make it match the rewording of the second note (which previously existed in the draft of the Understanding document, but not of the guideline document).
Altering "would be" to "is" as per requests by Bruce in other new SCs
Updates to Understanding document to match the proposed notes.
| <p class="note">If the interface is configurable so that the user can reposition content such as toolbars and non-modal dialogs, then only the initial positions of user-movable content would be considered for testing and conformance of this Success Criterion.</p> | ||
| <p class="note">Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content is considered for testing and conformance of this Success Criterion.</p> | ||
|
|
||
| <p class="note">Where content disclosed by the <em>user</em> can obscure other content, if the user can reveal the item with focus without moving keyboard focus (for example, by dismissing with Esc), such disclosed content is not considered to fully obscure the item receiving focus.</p> |
There was a problem hiding this comment.
@mbgower thanks for making this two notes. I do not think "disclosed" is a great word to use this paragraph. I also think the note might track closer to SC phrasing. My attempt:
Where user interaction causes new content to obscure other content, if the user can visually expose the component with focus without moving keyboard focus (for example, by dismissing with <kbd>Esc</kbd>), then the component is not entirely hidden.
There was a problem hiding this comment.
Thanks, @bruce-usab I'm concerned that the suggested text "Where user interaction can cause new content to obscure other content..." may be a little broad. We want to 'except' content the user directly opens. We don't want this to be interpreted as meaning that anything that occurs as a result of any user interaction (e.g., tabbing through the UI, populating a user input, answering a prompt, etc) could lead to a loss of focus. Obviously if the user isn't aware an 'interaction' of theirs has potentially obscured focus, they won't know to 'uncover' it.
Other suggestions welcome!
There was a problem hiding this comment.
I agree that the term "disclose" is odd in an interface context. How about "opens", or "reveals"?
There was a problem hiding this comment.
@mbgower I concede that my phrasing could be too broad. I was trying to introduce as few new words as possible, and make the exception a little more active voice. "Reveals" seems better (more generic) to me than "opens"..
Matched the latest feedback on wording and also attempted to add more context on persistent versus non-persistent content
Added a reference to a knowbility article
Added placeholders for possible future illustrations
|
@alastc Should this content be visible in the Understanding document: https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html? |
|
@mbgower Should this content be visible in the Understanding document: https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html ? This is referenced as closing my issue #2751, but it isn't appearing in the WCAG 2.2 CR? |
|
it's been merged into https://github.com/w3c/wcag/tree/FocusObscured-suggested-changes but not the main branch, which is why that's not showing up on the published version |
|
Yup, yup, I see that, hence my question about "should" it be visible in the Understanding doc. That is the intention, yes? |
|
It should have been, but the branching got confused, I've added this as the first question for today's meeting (WCAG 2.x wise) to check everyone's happy with that merge. |
Attempt to add an additional section on considerations to address #2751
Closes #2751
Preview of the understanding doc for the AA version.