Please put status bar objects in container with accessible role of status bar
Categories
(Thunderbird :: Disability Access, enhancement)
Tracking
(thunderbird_esr68 fixed, thunderbird75 fixed)
People
(Reporter: jdiggs, Assigned: Paenglab)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
8.33 KB,
patch
|
mkmelin
:
review+
wsmwk
:
approval-comm-beta+
|
Details | Diff | Splinter Review |
7.98 KB,
patch
|
wsmwk
:
approval-comm-esr68+
|
Details | Diff | Splinter Review |
Steps to reproduce:
- Launch Thunderbird (latest stable or Daily)
- Use Accerciser to locate the status bar
Expected results: There would be a container with the accessible role of status bar which contains the items at the bottom of the window.
Actual results: There is no such container.
Impact: Orca's command to read the status bar fails to read the objects which function as the status bar.
According to an Orca user, this worked with version 52 of Thunderbird. I myself am not sure when this stopped working. (Nor do I have time to investigate that. Sorry!)
While Orca could get logic to try to piece together the objects which function as a status bar, it would be much nicer if there were a container with the appropriate role so that Orca could know for certain that it should present those things when the command to read the status bar is given. Thanks!
Comment 1•4 years ago
|
||
According to https://developer.mozilla.org/en-US/docs/Web/CSS/appearance the -moz-appearance: statusbar
CSS property was removed in Firefox 64. AFAIU the new way is to use the dedicated <statusbar>
element. Changing the hbox to a statusbar indeed makes an element of "statusbar" role appear (in the devtool accessibility pane, I didn't manage to use accerciser here).
I'm inlining the test diff here, because other occurrences of this seem to lay around in Thunderbird and I don't know if a switch is in progress or how these global changes are to be handled.
diff --git a/mail/base/content/messenger.xhtml b/mail/base/content/messenger.xhtml
index 68cb81c53d..f8bdb7dc4f 100644
--- a/mail/base/content/messenger.xhtml
+++ b/mail/base/content/messenger.xhtml
@@ -922,7 +922,7 @@
<!-- notificationbox will be added here lazily. -->
</hbox>
<statuspanel id="statusbar-display"/>
- <hbox id="status-bar" class="statusbar chromeclass-status">
+ <statusbar id="status-bar" class="statusbar chromeclass-status">
#include mainStatusbar.inc.xhtml
<hbox id="calendar-invitations-panel"
class="statusbarpanel"
@@ -935,6 +935,6 @@
<label id="unreadMessageCount" class="statusbarpanel"/>
<label id="totalMessageCount" class="statusbarpanel"/>
#include ../../../calendar/lightning/content/calendar-status-bar.inc.xhtml
- </hbox>
+ </statusbar>
</window>
Comment 2•4 years ago
|
||
(In reply to Jonathan Michalon from comment #1)
According to https://developer.mozilla.org/en-US/docs/Web/CSS/appearance the
-moz-appearance: statusbar
CSS property was removed in Firefox 64. AFAIU the new way is to use the dedicated<statusbar>
element. Changing the hbox to a statusbar indeed makes an element of "statusbar" role appear (in the devtool accessibility pane, I didn't manage to use accerciser here).I'm inlining the test diff here, because other occurrences of this seem to lay around in Thunderbird and I don't know if a switch is in progress or how these global changes are to be handled.
diff --git a/mail/base/content/messenger.xhtml b/mail/base/content/messenger.xhtml index 68cb81c53d..f8bdb7dc4f 100644 --- a/mail/base/content/messenger.xhtml +++ b/mail/base/content/messenger.xhtml @@ -922,7 +922,7 @@ <!-- notificationbox will be added here lazily. --> </hbox> <statuspanel id="statusbar-display"/> - <hbox id="status-bar" class="statusbar chromeclass-status"> + <statusbar id="status-bar" class="statusbar chromeclass-status"> #include mainStatusbar.inc.xhtml <hbox id="calendar-invitations-panel" class="statusbarpanel" @@ -935,6 +935,6 @@ <label id="unreadMessageCount" class="statusbarpanel"/> <label id="totalMessageCount" class="statusbarpanel"/> #include ../../../calendar/lightning/content/calendar-status-bar.inc.xhtml - </hbox> + </statusbar> </window>
Add Magnus to need info because he could probably tell us the way to go.
Many thanks Jo for looking at this.
Best regards.
Assignee | ||
Comment 3•4 years ago
|
||
Joanmarie or Alex, could you check the Address book statusbar if it works as you want? This is the only one which has still the <statusbar> element.
Comment 4•4 years ago
|
||
Yes it works there (Alex confirmed and I checked later). But it seems there are other locations with that CSS property like chat or search/filter but I didn't manage to open them right now…
Assignee | ||
Comment 5•4 years ago
|
||
This changes all <hbox> statusbars to <statusbar>. I leave the class to make it possible to revert if m-c decides to remove the <statusbar> element.
Comment 6•4 years ago
|
||
For reference, statusbar was removed in bug 1419170. It would be a bit odd to add it since it's not a thing now...
I wonder if adding role="status" would fix this?
Assignee | ||
Comment 7•4 years ago
|
||
M-C has still one in a test: https://searchfox.org/mozilla-central/source/accessible/tests/mochitest/role/test_general.xhtml#57
The binding was removed but the element seems still to work.
Comment 8•4 years ago
|
||
I let Jonathan check the Magnus proposal. We work together and I've explained to Jonathan how to check if it is fixed with Orca.
Comment 9•4 years ago
|
||
AFAIU from https://hg.mozilla.org/integration/mozilla-inbound/rev/38f11a0d4111 they removed some sort of "manual" binding of xul:statusbar but still in the same commit, add a XULMAP and a constructor. Looks more like tid'up? This would mean that the element way is the way to go instead of CSS class or explicit role or whatever.
I wanted to test quickly on 68.5 but in the meantime there was a switch from xul files to xhtml… maybe related to the switch to distinct elements. About role I didn't see a change in the accessibility pane of dev tool but at the same time I didn't find the role in the inspector so maybe I did a mistake…
Comment 10•4 years ago
|
||
I don't know for Thunderbird 68 but with Daily I confirm that adding the role status on the statusbar works.
Assignee | ||
Comment 11•4 years ago
|
||
This time with the role="status".
Comment 12•4 years ago
|
||
Comment on attachment 9132899 [details] [diff] [review] 1621287-hbox-to-statusbar.patch Review of attachment 9132899 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!! Good that we could avoid adding a basically defunct <statusbar> since at some point it would need to be converted to something else.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 13•4 years ago
|
||
Updated•4 years ago
|
Comment 14•4 years ago
|
||
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/ef40d5b3cb73
Use on the <hbox> statusbar role="status" to make it accessible. r=mkmelin
Updated•4 years ago
|
Comment 15•4 years ago
|
||
bugherder uplift |
Thunderbird 75.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/6e432fce3e4c
Updated•4 years ago
|
Comment 16•4 years ago
|
||
Comment on attachment 9132981 [details] [diff] [review] 1621287-hbox-to-statusbar-ESR.patch Approved for ESR
Comment 17•4 years ago
|
||
Thunderbird 68.7: https://hg.mozilla.org/releases/comm-esr68/rev/40ad5a91482eb2692c72057d9fa8a935103d3989
Description
•