Closed Bug 1621287 Opened 5 months ago Closed 5 months ago

Please put status bar objects in container with accessible role of status bar

Categories

(Thunderbird :: Disability Access, enhancement)

enhancement
Not set
normal

Tracking

(thunderbird_esr68 fixed, thunderbird75 fixed)

RESOLVED FIXED
Thunderbird 76.0
Tracking Status
thunderbird_esr68 --- fixed
thunderbird75 --- fixed

People

(Reporter: jdiggs, Assigned: Paenglab)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 1 obsolete file)

Steps to reproduce:

  1. Launch Thunderbird (latest stable or Daily)
  2. 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!

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>

(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.

Flags: needinfo?(mkmelin+mozilla)

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.

Flags: needinfo?(jdiggs)

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…

Attached patch 1621287-hbox-to-statusbar.patch (obsolete) — Splinter Review

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.

Assignee: nobody → richard.marti
Status: NEW → ASSIGNED
Attachment #9132341 - Flags: review?(mkmelin+mozilla)

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?

Flags: needinfo?(mkmelin+mozilla)

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.

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.

Flags: needinfo?(jdiggs) → needinfo?(john)

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…

Flags: needinfo?(john)

I don't know for Thunderbird 68 but with Daily I confirm that adding the role status on the statusbar works.

This time with the role="status".

Attachment #9132341 - Attachment is obsolete: true
Attachment #9132341 - Flags: review?(mkmelin+mozilla)
Attachment #9132899 - Flags: review?(mkmelin+mozilla)
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.
Attachment #9132899 - Flags: review?(mkmelin+mozilla) → review+
Attachment #9132899 - Flags: approval-comm-beta?
Attachment #9132981 - Flags: approval-comm-esr68?
Target Milestone: --- → Thunderbird 76.0

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

Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Attachment #9132899 - Flags: approval-comm-beta? → approval-comm-beta+
Comment on attachment 9132981 [details] [diff] [review]
1621287-hbox-to-statusbar-ESR.patch

Approved for ESR
Attachment #9132981 - Flags: approval-comm-esr68? → approval-comm-esr68+
Regressions: 1628891
You need to log in before you can comment on or make changes to this bug.