Support role=application TV apps #8
Conversation
hugoholgersson
force-pushed
the
master
branch
2 times, most recently
from
d14ef98
to
127f421
Compare
hugoholgersson
force-pushed
the
master
branch
from
127f421
to
18a3d45
Compare
|
Friendly ping. This change unlocks accessibility on several TV apps. |
|
Thank you very much Hugo for your Pull request! This is a known issue and we are working on resolving it. We will address the issue by other means. |
|
Ok! Can you share your plan forward? Will TalkBack support role=application's semantics? |
|
Can you share your plan forward? Will TalkBack support role=application's semantics? |
hugoholgersson
force-pushed
the
master
branch
from
18a3d45
to
54d337f
Compare
Ok, let me know if you need a beta tester/reviewer. :-)
To not only support WebView-based apps, in |
hugoholgersson
force-pushed
the
master
branch
2 times, most recently
from
650ba28
to
bc2c99a
Compare
|
@hugoholgersson consider also adding this pull request to project which is actively maintained Talkback FOSS. It would be nice to see it there. |
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.
hugoholgersson
force-pushed
the
master
branch
from
bc2c99a
to
1ed4eef
Compare
|
Thanks @PatrykMis. My hope is to have this reviewed and accepted here, upstream. Do you want to review/test it, before I ask the owners to take a (new) look? I did this patch for TB 6.1 originally. We have used it in production for over a year to support one of our TV apps. I have now rebased it to TB 9.1 (latest here at GitHub) since TB 9.1, despite its improvements, still lacks support for role=application. |
|
They don't appear to accept contributions from outside Google, unfortunately. |
|
@thestinger Yes, it is completely different version of Accessibility Services than this one on Play Store. I've talked with person who worked in Google on TalkBack and unfortunately you are absolutely right. They are even not interested to have new testers, not to mention developers improving their code. That's why in blind community, the Chinese closed-source, unsafe with danger probability app Jieshuo (Commentary) is very popular as replacement for unmaintained, slow and heavy TalkBack. That's why I am trying to do something and created the fork. @hugoholgersson I can test it if I would know at least one app with |
|
@hugoholgersson is your PR still applicable for latest Talkback (pushed on 8 jan)? |
|
@thestinger Unfortunately that's true as stated in this comment |
This is the first PR we do for TalkBack. PTAL :)