GNOME Bugzilla – Bug 522798
Yahoo mail "button menus" are difficult to access
Last modified: 2008-05-16 16:43:35 UTC
1. open a message in yahoo mail using the classic interface. 2. tab to the forward button. 3. Press enter. 4. Notice that nothing happens. This was noted by a possible new orca user at CSUN. Joanie did quite a bit of investigation into this bug at the show so I'll let her add more details.
Thanks for filing this Mike. > 4. Notice that nothing happens. That's not entirely true. An unordered list that is functioning as a menu appears beneath the button. Sadly, due to CM, these items are at the end of the accessible hierarchy (and for that matter the DOM). If you arrow down past the message you'll eventually find the "menu" items. (Marco and I found the same thing using JAWS, btw.) I've opened the following bug for that issue: https://bugzilla.mozilla.org/show_bug.cgi?id=423364 Functional relations established by javascript should be reflected in the accessible hierarchy In the meantime, that's only half of the problem. The other half of the problem is what to do once you finally get to the blessed "menu" item that you want. Pressing Enter on it does nothing. More CM: those items have an onclick handler, but are not actually focusable. But if you you arrow to one of them and then use flat review to click on it, you can do it. So.... It is indeed possible to forward messages using Yahoo mail; it just sucks to do so thanks to the way the page is marked up. :-( Changing the summary and severity to reflect that. Not *yet* marking this as blocked because I want to see if I can make things suck less. I'm not convinced that I can, but I'm not yet convinced that I can't either. :-)
Okay, I just played around with this a bit more. Here's the deal: 1. When the "menu" appears, we get an object:children-changed:add event. 2. onChildrenChanged() takes a look at it to see if we want to handle it as a live region. 3. handleAsLiveRegion() sees that the event doesn't end with 'system' (which we expect, since this is a user action), does a "just in case" check to see if it is an alert (it's not), and returns False. 4. onChildrenChanged() doesn't do anything with items that are not seen as live regions, so we don't say anything. I assume that this will be the case for any site where widgets are faked via javascript manipulation of HTML. Questions: 1. Should we check for object:children-changed:add events that a. don't end with 'system' (i.e. the user caused it) b. have an associated action (i.e. the user can interact with the object that they just caused to get added) if so: 2. What should we do when we detect such a thing? a. Speak something useful to let the user know this has occurred? b. Give the user the ability to move there? (remember, we cannot predict where these things might turn up in the hierarchy) c. Something else? if we do give the user the ability to move there: 3. Should we give the user the ability to quickly move back (because the thing might be useless in addition to being who knows where w.r.t. our previous location)? I definitely need thoughts. If we want to actually do something to handle this sort of thing, I'll also need a spec along with an indication of where this fits in our list of priorities. :-) Thanks!
> c. Something else? I'm not sure, but this kind of seems like really crappy markup, especially since it doesn't seem to be keyboard accessible. I'm tempted to say "Dear Yahoo, your content in inaccessible..." Don't we also have a friend there (VictorT) who can help push this internally?
I'll email Victor about this. Perhaps we should close this bug as we really can't do anything about it.
I've since spoken with Mike about this and we agreed to close it as WONTFIX.