Let web developers signal their "DPAD mechanics" #1049
Comments
|
Can you explain how this is different to role=application? Note - we really try not to encourage use of role=application as it makes it much more difficult to use many of the ways that screen reader users use to navigate pages. |
|
Thanks. I didn't know of role=application. I guess TV apps like YouTube TV should use this role?
Yeah. What I request is a way for authors to not only hint "we're handling focus movements on our own" (role=application) but also 1) hint how focus movements are handled so 2) for dpad="browser", actually trigger the browser to go into Spatial Navigation mode. 1) and 2) are implementation details the screen reader doesn't need to know about.
role=application sounds like a good thing. I don't want to change it. I think my suggestion, since it's not only describing the content but also potentially triggers Spatial Navigation, makes more sense in another spec. A screen reader doesn't need to know how focus movements are implemented by the app.
Understood. role=application means the author must take full responsibility for focus movements. Imagine
Does that make sense? (There's no new, locked down, role here so the risk of misuse is the same.) |
I think that's not the case. The following may be too far apart from what @hugoholgersson has in mind but let me write it down and if it turns out to be off-topic, I'll hide the comment. I'm quite interested in the topic of "something less extensive than role=application". That is, ways to provide AT with more information about the content structure and preferred navigation as intended by an author while keeping AT's ability to override where needed. An existing example are table walkers provided by most screenreaders. They allow two dimensional navigation as opposed to the linear reading modes and positional information, purely from HTML markup (in particular, no JS). An example of a role that I think could become or lead to another example would be role=tree. That is, AT could provide treewalkers much like it provides table walkers (e.g., depth-first, breadth first). I like role=tree because it is already an example of slowly reducing authoring complexity: setting active-descendant vs moving tabindex, creating aria-setsize, aria-posinset, aria-level vs browsers calculating those automatically. In the light of this history, it does not seem too far fetched to work across the stack to ensure AT can provide basic tree navigation while allowing authors to nevertheless do fancier (optional) navigation via JS (e.g., cyclical navigation on a tree level can be very helpful in SVG content). |
Thanks for the feedback but let's try to keep this discussion about role=application. For role=application, isn't it enough for the screen reader to passively receive events about where focus went (it does not need the logic behind why focus moved the way it did)?
Chrome's Spatial Navigation can walk tables, and many other structures, just fine (but it can only jump between focusables!). Chrome's Spatial Navigation is really just heuristics for finding the closest, focusable element up/down/left/right of current focus. Sure, SpatNav's output could probably be valuable to screen readers in a broader context but not when it comes to |
|
We discussed this issue on the ARIA WG call on Sept 26. It's not clear to the WG how this issue relates to ARIA. The problem appears to be primarily about how Assisitive Technology focus management interacts with the CSS spatial navigation spec. We would suggest to perhaps start a discussion on the spatial navigation end so as to identify issues that relate to accessibility in general and ARIA (or related) specs in particular. In fact, there already has been some discussion around (the trouble of) focus managment, cf. w3c/csswg-drafts#3379 which seems like a good place to continue fleshing out this problem. |
Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps loose their 4-way (up/down/left/right) navigation. TalkBack only moves foward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to a WebView with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: From TalkBack's test app, open dpad_a11y.html which has <body role=application>. Notice: I. Once the WebView gets accessibilty focus, TalkBack won't consume DPAD key events. II. The key events reach the web page's key handlers in JavaScript. III: TalkBack describes HTML elements once they get focused. Change-Id: I6110ec8adec1e827ee523559e08dc3f79c5ca515 Signed-off-by: Hugo Holgersson <[email protected]>
Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps loose their 4-way (up/down/left/right) navigation. TalkBack only moves foward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to a WebView with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: From TalkBack's test app, open dpad_a11y.html which has <body role=application>. Notice: I. Once the WebView gets accessibilty focus, TalkBack won't consume DPAD key events. II. The key events reach the web page's key handlers in JavaScript. III: TalkBack describes HTML elements once they get focused.
Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps loose their 4-way (up/down/left/right) navigation. TalkBack only moves foward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to a WebView with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: From TalkBack's test app, open dpad_a11y.html which has <body role=application>. Notice: I. Once the WebView gets accessibilty focus, TalkBack won't consume DPAD key events. II. The key events reach the web page's key handlers in JavaScript. III: TalkBack describes HTML elements once they get focused.
Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps loose their 4-way (up/down/left/right) navigation. TalkBack only moves foward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to a WebView with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: From TalkBack's test app, open dpad_a11y.html which has <body role=application>. Notice: I. Once the WebView gets accessibilty focus, TalkBack won't consume DPAD key events. II. The key events reach the web page's key handlers in JavaScript. III: TalkBack describes HTML elements once they get focused.
Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps loose their 4-way (up/down/left/right) navigation. TalkBack only moves foward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to a WebView with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: From TalkBack's test app, open dpad_a11y.html which has <body role=application>. Notice: I. Once the WebView gets accessibilty focus, TalkBack won't consume DPAD key events. II. The key events reach the web page's key handlers in JavaScript. III: TalkBack describes HTML elements once they get focused.
Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps lose their 4-way (up/down/left/right) navigation. TalkBack only moves foward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to a WebView with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: From TalkBack's test app, open dpad_a11y.html which has <body role=application>. Notice: I. Once the WebView gets accessibilty focus, TalkBack won't consume DPAD key events. II. The key events reach the web page's key handlers in JavaScript. III: TalkBack describes HTML elements once they get focused.
Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps lose their 4-way (up/down/left/right) navigation. TalkBack only moves forward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to some web content with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: From TalkBack's test app, open dpad_a11y.html which has <body role=application>. $ cd testapp $ export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 $ export ANDROID_HOME=~/AndroidSDK $ ./gradlew --debug assemble $ adb install -r app/build/outputs/apk/app-debug.apk $ adb shell am start -n com.android.talkbacktests/.MainActivity Notice: I. Once the WebView gets accessibilty focus, TalkBack won't consume DPAD key events. II. The key events reach the web page's key handlers in JavaScript. III: TalkBack describes HTML elements once they get focused. Signed-off-by: Hugo Holgersson <[email protected]>
After: The green rect follows web focus. Before: TalkBack tries to read the TV apps as a textual documents. Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus. I learned this through: w3c/aria#1049 Problem: TalkBack completely neglects role=application. Solution: Whenever accessibility focus (the green rect) goes to a WebView with <body role=application> or anywhere within such a document, don't consume the DPAD events; let them through. Testing done: Open a simple TV web app that has <body role=application>. Notice: Once the web view gets accessibilty focus, TalkBack won't eat (consume) DPAD key events and the the key events reach the web page's key handler in JavaScript. Signed-off-by: Hugo Holgersson <[email protected]>
After: The green rect follows web focus. Before: TalkBack tries to read the TV apps as text documents. Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps lose their 4-way (up/down/left/right) navigation. TalkBack only moves forward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to some web content with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: Open a simple TV web app that has <body role=application>. Notice: Once the web view gets accessibilty focus, TalkBack won't eat (consume) DPAD key events and the the key events reach the web page's key handler in JavaScript.
After: The green rect follows web focus. Before: TalkBack tries to read the TV apps as text documents. Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps lose their 4-way (up/down/left/right) navigation. TalkBack only moves forward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to some web content with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: Open a simple TV web app that has <body role=application>. Notice: Once the web view gets accessibilty focus, TalkBack won't eat (consume) DPAD key events and the the key events reach the web page's key handler in JavaScript.
After: The green rect follows web focus. Before: TalkBack tries to read TV apps as text documents. Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps lose their 4-way (up/down/left/right) navigation. TalkBack only moves forward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to some web content with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: Open a simple TV web app, hosted in an Android WebView, that has <body role=application>. Notice: Once the web view gets accessibilty focus, TalkBack won't eat (consume) DPAD key events and the the key events reach the web page's key handler in JavaScript.
After: The green rect follows web focus. Before: TalkBack tries to read the TV apps as text documents. Background: Within <xxx role=application>...</xxx>, screen readers should not consume DPAD (arrow key) events. Web apps or widgets with role=application have, per the WAI-ARIA spec's contract, their own JavaScript logic for moving focus [1]. [1] w3c/aria#1049, where we discussed this. Problem: TalkBack does not handle role=application so such web apps lose their 4-way (up/down/left/right) navigation. TalkBack only moves forward/backward which breaks authors' pre-defined TV UX. Solution: Whenever accessibility focus (the green rect) goes to some web content with <body role=application> or anywhere within a role=application widget, we don't consume the DPAD events; we let them through. Testing done: Open a simple TV web app that has <body role=application>. Notice: Once the web view gets accessibilty focus, TalkBack won't eat (consume) DPAD key events and the the key events reach the web page's key handler in JavaScript.
Background
When users browse the web on their TV, the remote's directional pad, "the DPAD" (usually 4 arrow keys), is often the only input device available.
Most web apps have custom JS to move focus upon DPAD (or, more generically, arrow key) input. However, Chromium's built-in "focus moving logic", Spatial Navigation, has become better the last few years so app authors might now choose to offload their JS' "focus movement"-logic to the browser.
General problem
A browser cannot know if a web app has either:
Accessibility problem
Some screen readers, such as TalkBack on Android TV, walk web pages sequentially, even if the app has its own DPAD-logic in JavaScript.
When TalkBack reads a TV web app with built-in DPAD support, TalkBack moves focus sequentially (think Tab/Shift+Tab) even though the web app has its own DPAD-logic. => The web app's UX degrades from 2D to 1D directional navigation only because the user enabled her screen reader!
Suggestion
An attribute, for now let's call it
dpad, that gives the browser (and screen readers) a hint about how the author expects focus movement/highlighting to happen:Example:
Here the attribute indicates how navigation is supposed to work within the document.
Most TV apps use one strategy for the entire app so the primary (or only?) use case would be to put the attribute on the document
<body>.In all cases, a screen reader may still emphasize
activeElementthe way TalkBack does with its green rectangle above the web content. A rectangle on top of the content, rendered outside the browser, is fine because it will not conflict with the web page's:focusCSS.Follow-up
<body dpad="..">is the primary use case but, as a follow-up,<div dpad="..">could be a hook for web developers (or custom element developers) to control focus management within widgets (DOM sub trees).Possible implementation
When
activeElementis within adpad="js" / "browser"sub tree, the browser could expose a one-node accessibility tree that only consists ofactiveElement. This would force screen readers to only speak aboutactiveElement, keep it from navigating elsewhere and, instead, let the DPAD/arrow key events through to the web page.The text was updated successfully, but these errors were encountered: