Last modified: 2014-08-11 23:17:44 UTC
Relevant background: http://www.w3.org/WAI/GL/wiki/Using_ARIA_menus http://stackoverflow.com/questions/12279113/recommended-wai-aria-implementation-for-navigation-bar-menu Good: * Usage of links which are native navigable elements * use of ul and li, which are native elements with semantic structure. Bad: * When the drop down receives focus, it should automatically uncollapse, Focus should match the hover state is more than just decoration. Improve: * The user page link should have aria-haspopup="true", aria-controls to indicate that it is responsible for controlling the submenu. * Add aria-hidden: to the primary ul in the flyout to reflect it's 'visibility' to screen readers. * aria-expanded="true/false" to reflect the * Make it an actual menu: ul[role=menu] > li[role=presentation] > a[role=menuitem] * When doing so make sure you add arrow/enter/space keyboard shortcuts * role menubar on the entire p-personal, role=menuitem on the individual pt-icons BTW: Would advise to add a 'CPB ready' event, so that other scripts can hook into it.
DJ, do you plan on working on this? or just the audit (either is appreciated) just checking. Thanks for the work so far!
I haven't planned anything right now. It depends on my time. Took me 2 months to get around to the review ;)
Thanks for this. I can add those points. We have to keep in mind though that most of the JS code for CPB should be disposed of. It should be simply generated in PHP when it's no longer a beta feature. The unfolding of menu is already CSS-only. Therefore, I'm not sure if there's a point in introducing a CPB-ready event if we were to deprecate it in just a couple of months.