Closed Bug 955067 Opened 10 years ago Closed 10 years ago

accessibility: Lists in main window are unlabelled

Categories

(Instantbird Graveyard :: Contacts window, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: florian)

Details

Attachments

(1 file)

*** Original post on bio 1637 by James Teh <jamie AT nvaccess.org> at 2012-08-09 13:27:00 UTC ***

The "Conversations on hold" and "Contacts" lists are unlabelled in terms of accessibility. This should be pretty simple to fix using the aria-labelledby attribute:
1. The node with @id="convlistbox" should have @aria-labelledby="convsHeader".
2. The node with @id="buddylistbox" should have @aria-labelledby="contactsHeader".
*** Original post on bio 1637 as attmnt 1799 at 2012-08-09 13:38:00 UTC ***

Wouldn't using the control attribute on the labels do what you want, but with the added benefit that clicking these labels now do something for users no using the accessibility tools?
Attachment #8353558 - Flags: review?(bugzilla)
Comment on attachment 8353558 [details] [diff] [review]
Patch adding control attributes on the labels

*** Original change on bio 1637 attmnt 1799 at 2012-08-09 13:41:32 UTC ***

Looks good.
Attachment #8353558 - Flags: review?(bugzilla) → review+
*** Original post on bio 1637 at 2012-08-09 13:42:10 UTC ***

Assigning...
Assignee: nobody → florian
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
*** Original post on bio 1637 by James Teh <jamie AT nvaccess.org> at 2012-08-09 14:42:21 UTC ***

(In reply to comment #1)
> Wouldn't using the control attribute on the labels do what you want, but with
> the added benefit that clicking these labels now do something for users no
> using the accessibility tools?
Sounds great. I only gave the aria-labelledby tip for two reasons:
1. I don't know much about XUL; and
2. People often want a solution that doesn't impact anything else for other users. :)
*** Original post on bio 1637 at 2012-08-09 14:53:09 UTC ***

(In reply to comment #4)
> (In reply to comment #1)
> > Wouldn't using the control attribute on the labels do what you want, but with
> > the added benefit that clicking these labels now do something for users no
> > using the accessibility tools?
> Sounds great. I only gave the aria-labelledby tip for two reasons:
> 1. I don't know much about XUL; and

It's ok, your bug reports are great! We don't know much about accessibility (except that when using the XUL platform we get it mostly right almost for free thanks for Mozilla's accessibility efforts) so your help to diagnose the issues is really appreciated.

> 2. People often want a solution that doesn't impact anything else for other
> users. :)

I guessed that; however if the thing we add for accessibility reasons can have a slightly positive effect for other users, we are less likely to regress it later :).

Anyway, thanks for your help!
Whiteboard: [checkin-needed]
*** Original post on bio 1637 at 2012-08-21 13:28:24 UTC ***

https://hg.instantbird.org/instantbird/rev/4006bc908917
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
OS: Windows 7 → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → 1.3
Whiteboard: [checkin-needed]
*** Original post on bio 1637 by James Teh <jamie AT nvaccess.org> at 2012-08-28 01:34:30 UTC ***

Unfortunately, this isn't fixed for me in version 1.3a1pre (20120827042551). Oddly, I can't see the label objects in the accessibility hierarchy any more either.
*** Original post on bio 1637 by jamie AT nvaccess.org at 2012-08-28 01:46:55 UTC ***

Reopening as per comment 7.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Original post on bio 1637 by James Teh <jamie AT nvaccess.org> at 2012-08-28 01:51:58 UTC ***

This is rather odd. If there are no conversations on hold, both lists are unlabelled according to accessibility. However, when there is at least one conversation on hold, both lists become labelled. They become unlabelled again as soon as there are no conversations on hold once again.
*** Original post on bio 1637 by jamie AT nvaccess.org at 2012-08-28 02:03:48 UTC ***

Sorry for the bug spam. :)

I'm guessing these labels actually visually disappear when there are no conversations on hold, which makes some sense since only one list is really visible. (Certainly, the hold list has a width of 182 and height of 0, which suggests it isn't visible.) Therefore, I'm closing this as fixed again.

The hold list should probably be removed from the tab order when this occurs. Also, it's not exposing the invisible state to accessibility. I'm not sure why.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
*** Original post on bio 1637 by jamie AT nvaccess.org at 2012-08-28 02:05:03 UTC ***

Verified fixed in version 1.3a1pre (20120827042551).
Status: RESOLVED → VERIFIED
*** Original post on bio 1637 at 2012-08-28 09:04:12 UTC ***

(In reply to comment #10)

> The hold list should probably be removed from the tab order when this occurs.

This means we just need to set disabled=true on it when it's invisible, right? Are you going to file a bug on this so that we don't forget it? :-)

> Also, it's not exposing the invisible state to accessibility. I'm not sure why.

I'm not sure of what needs to be done for this. Or do we need to use a collapsed=true XUL attribute instead of display: none in CSS?
*** Original post on bio 1637 at 2012-08-28 09:08:16 UTC ***

(In reply to comment #12)
> (In reply to comment #10)
> 
> > The hold list should probably be removed from the tab order when this occurs.
> 
> This means we just need to set disabled=true on it when it's invisible, right?
> Are you going to file a bug on this so that we don't forget it? :-)
I believe I already fixed this in a different way in the patch for bug 955087 (bio 1658)?
*** Original post on bio 1637 by James Teh <jamie AT nvaccess.org> at 2012-08-28 09:14:47 UTC ***

(In reply to comment #13)
> > > The hold list should probably be removed from the tab order when this occurs.
> I believe I already fixed this in a different way in the patch for bug 955087 (bio 1658)?
From the description, it seems so.


(In reply to comment #12)
> > Also, it's not exposing the invisible state to accessibility. I'm not sure why.
> I'm not sure of what needs to be done for this. Or do we need to use a
> collapsed=true XUL attribute instead of display: none in CSS?
display: none should do the trick - it does in HTML - so I'm not sure why this isn't working. Perhaps it's failing because the list is still focusable. I'll file a follow up if this is still an issue after bug 955087 (bio 1658) lands.
You need to log in before you can comment on or make changes to this bug.