[Webkit-unassigned] [Bug 239295] New: AX: UsableNet re: inconsistency in hidden contents behind aria-modal dialogs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=239295

            Bug ID: 239295
           Summary: AX: UsableNet re: inconsistency in hidden contents
                    behind aria-modal dialogs
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Accessibility
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jcraig at apple.com
                CC: andresg_22 at apple.com,
                    webkit-bug-importer at group.apple.com

Bug report from from UsableNet re: inconsistency in hidden contents behind aria-modal dialogs.

Platform not specified, presuming a recent Mac release.

Quoting:
> Previously, VO with Safari "trapped" the user into the element with aria-modal="true" as expected. Today, VO with Safari is behaving inconsistently across multiple websites. This behaviour is happening in particular with elements injected in the DOM after page load.
> 
> For example, trying to navigate the modal example provided by the aria practices (https://www.w3.org/TR/wai-aria-practices-1.2/examples/dialog-modal/dialog.html) VO is still able to navigate the inert content available in the background (content provided outside the element with aria-modal="true").

It wasn't clear from the bug report if he was navigating by FKA Nav (Tab) or VO Nav (e.g. VO+Right). 

Report used the term "inert" which isn't the same as "hidden" contents behind an aria-modal dialog. True "inertness" can only be achieved with inert="" and/or the dialog API, not aria-modal or aria-hidden. The difference is only relevant to mention here because if full keyboard access tabbing results in focus of hidden content (if focused, by definition it is not inert) then the modal or hidden state should be ignored and the focused element should be exposed to accessibility. That's not true for actual inert content, which should never achieve focus.

The linked example is not a good one because it uses some mediocre focus trapping. The focus trapping doesn't really work, and the added complexity makes it a little harder to diagnose. I'm going to work on reducing a test case before further clarification.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220413/d89b952c/attachment.htm>