462411 - Add-on headings' expand/collapse features are inaccessible

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Collections, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Marco tells me that https://preview.addons.mozilla.org/en-US/firefox/collections/interactive is inaccessible in the following way:

"the screen reader does not know that these headings can be clicked to expand more content."

Comment 1

[Michael Morgan [:morgamic]]

We should have everything shown by default and close them with JS -- this way a screen reader would just approach the headings as headings and each add-on would be a member of that group below it the way a normal document flows.

Comment 2

[Fred Wenzel [:wenzel]]

(In reply to comment #1)
> We should have everything shown by default and close them with JS

That is how it is anyway. With JS disabled you see all content. However, installation does not currently work without JS.

Does the screen reader employ JS?

Comment 3

[Marco Zehe (:MarcoZ)]

(In reply to comment #2)
> Does the screen reader employ JS?

No, the screen reader will show to the user whichever the page displays, and dynamically update if something is shown or hidden. The problem is that the information that these headings can be clicked is not communicated to the screen reader.

CCing David Bolter who currently works with the Jquery team to put ARIA in, to see what input he might have on this particular widget.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

This is a jQuery UI bug. The widget in question is an accordion, and the ARIA semantics for accordions is still being discussed in the W3C. Once the specification resolves for accordion markup we will fix this in jQuery.

You can do a non-trivial custom fix in the meantime if you want; let me know if you want details on that. It will involve another onload handler to provide ARIA roles, states, and relationships, and handlers to update the ARIA states.

Comment 5

[Michael Morgan [:morgamic]]

Rey, please speak with David about a possible fix and provide some tips.  Thanks!

Comment 6

[Rey Bango]

David, email me what needs to happen and I'll get together with the UI team. I'm part of the jQuery Project team and can help direct the effort.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Created jQuery UI ticket: http://ui.jquery.com/bugs/ticket/3553

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Update: in case there is a rush on this, we have a patch up on the jQuery ticket; just please note http://ui.jquery.com/bugs/ticket/3553#comment:1

Comment 9

[Rey Bango]

David confirmed that kb accessibility for accordian is now in the jQuery UI trunk which should solve this issue. Is it too late to include this for Collections?

Comment 10

[Fred Wenzel [:wenzel]]

I can patch the accordion file in our jquery UI folder. It's not used anywhere else but in the collections.

Comment 11

[Fred Wenzel [:wenzel]]

David, Rey: Opening one section works fine (and navigating with the keyboard does, as well!) but when I want to close the same one, or open a different one, I get:

Error: options.toShow.outerHeight is not a function
Source File: .../js/jquery-ui/ui.accordion.js
Line: 356

The line in question is (I marked it with >>> here):
			var hideHeight = options.toHide.height(),
				showHeight = options.toShow.height(),
				difference = showHeight / hideHeight,
>>>				padding = options.toShow.outerHeight() - options.toShow.height(),
				margin = options.toShow.css('marginBottom'),
				overflow = options.toShow.css('overflow')
				tmargin = options.toShow.css('marginTop');

Any clue where that problem comes from? Do I have to change something in order to account for a recent API change?

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #11)

Frédéric, without looking to deeply, I suspect the trunk version of ui.accordion.js might require some updated functionality in other files.  I haven't seen that bug in any of my tests.

Comment 13

[Fred Wenzel [:wenzel]]

Ah, makes sense, thanks. I don't think I can update all of jquery UI at the moment without making sure it doesn't break other pages. I'll try to apply your patch from the bug only to our version of accordion, and if it works that's good, otherwise we'll have to do this as a complete jquery UI upgrade when it turns stable.

Comment 14

[Fred Wenzel [:wenzel]]

Attachment: using patched accordion JS

All right, I took the jquery 1.6.2rc2 bundle and patched accordion part with the patch from #3553. It works well. In order to not conflict with our current stable instance of jquery UI, I added this as a separate file. After this is part of the stable jquery UI release and we update to it, the file can go away.

Please also note that we can't blur() on change anymore, or else we'd make it hard to navigate by keyboard.

Comment 15

[Ryan Doherty (:rdoherty)]

Comment on attachment 348053 [details] [diff] [review]
using patched accordion JS

It does work when I tab to the first category header, but I can't tab to the rest of them. I think the tab indexes need to be sequential instead of all being -1.

Comment 16

[Fred Wenzel [:wenzel]]

(In reply to comment #15)
> (From update of attachment 348053 [details] [diff] [review])
> It does work when I tab to the first category header, but I can't tab to the
> rest of them. I think the tab indexes need to be sequential instead of all
> being -1.

David: That's a bug in your patch. Is there a reason why navigation with the tab key is not possible?

Comment 17

[Fred Wenzel [:wenzel]]

(In reply to comment #15)
> (From update of attachment 348053 [details] [diff] [review])
> It does work when I tab to the first category header, but I can't tab to the
> rest of them. I think the tab indexes need to be sequential instead of all
> being -1.

Ryan, can I commit this anyway, in order for this to be more accessible? After all, the patch improves the situation from "no way to navigate by keyboard" to "can be navigated with the arrow and enter keys".

Or do you think the missing tab key function is a deal breaker?

Comment 18

[Fred Wenzel [:wenzel]]

CCing rdoherty (see comment 17, please).

Comment 19

[Fred Wenzel [:wenzel]]

Lowering severity: There's nothing else I can do at the moment.

Comment 20

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #16)
> (In reply to comment #15)
> > (From update of attachment 348053 [details] [diff] [review] [details])
> > It does work when I tab to the first category header, but I can't tab to the
> > rest of them. I think the tab indexes need to be sequential instead of all
> > being -1.
> 
> David: That's a bug in your patch. Is there a reason why navigation with the
> tab key is not possible?

Sorry for late reply. That's NOTABUG :)  I'm following the DHTML Style guide for keyboard Ux.  ( see http://dev.aol.com/dhtml_style_guide )

Once you tab to the accordion, use arrows to move from header to header. Space/enter should select.

cheers!

Comment 21

[Fred Wenzel [:wenzel]]

David: Thank you for the answer! Since it's NOTABUG (or INVALID, as bugzilla dubs it), I mark this bug fixed, there's no additional work for us to do (other than update jQuery UI to its stable version once this is a11y fix is part of it.

Thanks for your good work.

Marco: If this is not fixed as intended, please feel free to reopen.

Comment 22

[Stephen Donner [:stephend] Not actively reading bugmail]

Marco, is this fixed for you now on https://preview.addons.mozilla.org/en-US/firefox/fashionyourfirefox?  Thanks!