+++ This bug was initially created as a clone of Bug #603800 +++ The header menus should support keyboard navigation. Feel free to use my jQuery-based code at http://mozilla.jp/ if you need.
Kohei, any chance you could make a patch for mozilla.com for this? We have a bunch of work to wrap up, if you could, it'd be a huge help.
Will try to make a patch for nova this weekend.
Assignee: nobody → abuchanan
Severity: normal → blocker
Created attachment 497261 [details] [diff] [review] patch * This assumes jquery.min.js is the latest version. (v1.3.2 is obsolete) * Implemented WAI-ARIA roles and attributes as a part of Bug 519325. * Stripped comment outs between <li>s. I thought those were workarounds for an IE bug but removing line breaks had the same effect. * Tested with Firefox 3.6/4b, IE 6/7/8, Chrome, Safari and Opera. Enjoy keyboard navigation!
Created attachment 497338 [details] screenshot of broken menu Thanks Kohei, this is very helpful. I've found a couple issues. 1) This breaks page validation. The main error is: An element with role=menuitem requires role=menu on the parent. I tried changing the role attributes, but I can't seem to get the page to validate. Could you help me out? I don't know enough about accessibility/ARIA yet, apparently. 2) When I hover Features or About, and then move my mouse directly to the left or right (respectively), the menu heading remains highlighted. I took a screenshot of the result (attached).
r79399 fixes this using most of Kohei's patch (Thanks again Kohei!) I had to remove many of the role attributes, because they were causing validation issues that I couldn't find a solution for. We can re-implement those post-launch.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
This broke the dropdown menus on the home page for non-Fx users (http://nova.stage.mozilla.com/en-US/firefox/new/). This is because we don't include jQuery for performance reasons. Is it possible to keep the ARIA stuff when JS is here and get a nice fallback with CSS if JS is not present?
We really shouldn't have different menu behaviour on the home page vs. other pages.
Committed r79466. I'm using a script to load those asynchronously and in parallel.
Created attachment 497861 [details] [diff] [review] fix focus issue 1) This breaks page validation. I have encountered the same issue. W3C validator may not fully support WAI-ARIA yet, especially doesn't understand role="presentation". <ul role="menu"> <li role="presentation"><a role="menuitem">Features</a></li> <ul> is valid, as an example in the spec shows: http://www.w3.org/TR/wai-aria/complete#presentation So such validation errors can be ignored... 2) When I hover Features or About, and then move my mouse directly to the left or right (respectively), the menu heading remains highlighted. Here's the patch!
About validation, does http://validator.nu/ helps ? I think it's more up-to-date regarding ARIA validation.
What's the status of this page? It's marked fixed, but comment #11 seems to indicate that there are still some issues.
We're good for launch. We need to file a separate bug to apply Kohei's changes in comment 11. Kohei, I think you're right, in this case we shouldn't be so worried about validation. Thanks for patching this.
Alex, do you mind filing that bug? I think it's safe to say you can provide a more accurate description of what needs to happen than I. When you file it, please be sure to give it the [post launch] whiteboard descriptor. Thanks!
(In reply to comment #15) > When you file it, please be sure to give it the [post launch] whiteboard > descriptor. Whoops, meant to say [post redesign] instead.
Committed r79521. The dynamic loading wasn't working on different domains (CDN).
Component: www.mozilla.org/firefox → www.mozilla.org
Product: Websites → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.