ENGAGE-531: Cabinet doesn't implement all of the necessary aria roles

Metadata

Source
ENGAGE-531
Type
Bug
Priority
Critical
Status
Closed
Resolution
Fixed
Assignee
Colin Clark
Reporter
Justin Obara
Created
2010-03-22T13:19:13.000-0400
Updated
2014-03-03T13:44:23.585-0500
Versions
  1. 0.3
Fixed Versions
  1. 0.3
Component
  1. Cabinet

Description

Cabinet doesn't implement all of the necessary aria roles

Each of the contents sections should be tabpanels

http://dev.aol.com/dhtml_style_guide#tabpanel

http://www.w3.org/WAI/PF/aria/roles#tabpanel

Comments

  • Justin Obara commented 2010-03-22T13:19:29.000-0400

    Bug Parade Engage 0.3

  • Justin Obara commented 2010-03-22T17:08:33.000-0400

    Moved the tab role and aria states from the Drawer to the Handle. Also added the tabpanel role to the Contents.

  • Justin Obara commented 2010-03-24T10:11:15.000-0400

    Assigned to Antranig for review

  • Antranig Basman commented 2010-03-25T09:35:35.000-0400

    The fix looks ok to me in terms of code, but assigning to Colin to verify that the use of ARIA roles is indeed correct. I suggest that the variable "selector" in drawerAdjust be renamed since by line 91 its use is deceptive, it is clearly no longer a selector but represents DOM nodes. This clarity should cascade upwards to the methods "openDrawers" and "closeDrawers" whose APIs should be better documented to explain their expectations - an idiom used elsewhere is to refer to a "jQueryable".
    I also suggest the uses of "move" be replaced with "adjust" - "move" suggests that the drawer nodes are to be physically shifted around the DOM, rather than just have their visual state adjusted. This would make consistency with the internal method named "drawerAdjust".