Focus Not Obscured needs a note for non-web software

[mbgower]

I believe there is a requirement for a note for WCAG2ICT to allow functionality built into non-web software (i.e., desktop applications) which is unavailable to web software. Without this note, software, which clearly has an existing mechanism for overcoming obscured content that is not covered by the existing wording of the SC, would regularly unnecessarily fail this SC.

Here is the suggested draft note:

Note: Where non-web software applications provide an ability for users to turn off the display of author-created content via the application menu (e.g., via the View menu), the component with focus is not considered visually hidden due to such author-created content, since users have a simple means of revealing the element that has received focus.

Rationale

1. Software in an environment that offers an application menu has a built-in OS method of launching the application menu (e.g, Alt key in Windows)
2. The modality of the application menu means a user can invoke it without any effect on the user’s current point of interaction in the main interface (which is the same litmus test allowed for one of the web notes)
3. If the display of the author-created content can be controlled from this modality, there is significantly less loss of ability for the user, even where the author-created content obscures the item with focus
4. After the display of a toolbar (for example) is turned off via the application menu, a user is returned to the main interface without their interaction point in that modality being affected. This meets the primary objective of the existing note's wording “If the user can reveal the focused component without advancing the keyboard focus”. Although the focus has been moved to the application menu and ‘advanced’ in that modality, in the context of the main interface, the focus is unaffected.

Currently, a note with a similar exception exists in web content where the user opens the content; however, in a software application, there can be multiple toolbars intentionally visible by default (even if they are minimized) to provide context to users. Such toolbars would potentially fail this SC, according to the existing wording, despite the fact there is no additional effort required by the user to close such content AND there is a decades-old, clearly established convention for users to use the View menu to remove visible toolbars in composition applications. @awkawk can likely speak to this need, from his time at Adobe.

[mraccess77]

The question I have is around the return of focus. If you go into the menu and then hide the toolbar and close the toolbar and go back to the main canvas- does focus return where you left off or do you need to tab many times to reach where you were?

The 2nd question is then do you ever need to use the toolbar and content that may be hidden behind it together or is there a way to scroll and have both shown? I have run into situations where I can hide the toolbars to get to the content - but then I can't have both at the same time creatin some restrictions on what can be done.

I think if both issues are addressed then such a technique makes sense as passing.

[mbgower]

For question 1, the application menu does not affect the focus in the main content window at all.
It is literally an operating system modality. When the user enters the application menu, their point of focus is retained in the main content, and returned there after exiting the application menu.

For question 2, the whole purpose of this modality is to have the toolbar and main content in the viewport at the same time, the user potentially scrolling or repositioing the 'main' space to work with different items on it in relation to the toolbars. So definitely they are intended to both be visible at once, or at least be operable that way. The main window would scroll independent of the toolbars, which are effectively 'locked' to one part of the viewport.
(There is also the ability in many for the user to reposition the toolbars; but that is very comparable to the existing movable note, and i don't think needs any additional consideration for non-web software).

[scottaohara]

this acknowledgement makes sense / would be welcome to me. there have been some apps i've reviewed recently where this would provide the developers a way to meet this SC - where as otherwise their options are limited since the overlaying content (non-modal dialogs / app-related windows) need to be present, but no matter where they are placed, they will obscure some content by default. it isn't a simple "oh redesign the app to include them in the primary app" or "just add a button in the main app to allow users to show/hide these instead".

[maryjom]

The TF had reviewed the proposed note on 2 May - See the Google doc with the proposed note, in context. See also the survey results, the meeting minutes where we had a discussion, and the TF resolution to not add the proposed note to 2.4.11 (Focus Not Obscured).

The TF revisited Focus Not Obscured in our extra Friday meeting on 24 May, and based on our conversation came up with a new proposal option 3 in the Google doc which we are surveying and will discuss on 30 May.

[maryjom]

On 30 May the TF reached consensus on the following note which will be added to Focus Not Obscured guidance:

Note: There are cases where non-web software has toolbars or other overlapping content where it may not be possible to satisfy this success criterion.

In this way, WCAG2ICT documents the issue without providing the solution for meeting and leaves it up to standards which apply WCAG in a non-web context to address (e.g. EN 301 549). It is outside of the WCAG2ICT scope of work to define techniques or ways of meeting an SC.

See the 30 May survey results and 30 May WCAG2ICT TF discussion and resolution from the minutes.

[maryjom]

Closing as answered. You may reopen this issue or a create a new one if this answer is not satisfactory.

[scottaohara]

the rational provided and the written note seem at odds with each other.

the added note appears to say "there are scenarios that cannot meet this SC"

but the issue was opened saying "there are scenarios that fall outside of the web guidelines, unique to non-web content, that should probably be considered as passes"

i don't see how that note is at all addressing the issue raised. Rather I read that note as potentially increasing the difficulty to make a case there are other ways to meet this SC than what is defined in the web understanding doc - which is the opposite of how I read the comment of "WCAG2ICT documents the issue without providing the solution for meeting and leaves it up to standards which apply WCAG in a non-web context to address (e.g. EN 301 549)"

are there examples that were reviewed / walked through that lead to this discrepancy? do examples (even reduced test cases) need to be provided to demonstrate the scenario? or since adding guidance for specific examples seems out of scope for this document, would it be best to just not add this note? And instead see if there aren't ways to address this topic in the understanding doc for this SC ? (not saying that may necessarily be possible - but at least then the outcome for this issue wouldn't be stating the opposite of what was hoped to be achieved)

[maryjom]

@scottaohara TF Final Answer to the comment posted on the reopened issue.

It is outside of WCAG2ICT Task Force’s scope to add the note that was originally asked for. Since the note that the Task Force previously consensed has an undesired effect, we have agreed to remove the note.