Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#9802 closed defect (fixed)

intermediate accessible between grid and row containing header cell is created

Reported by: Alexander Surkov Owned by: Becky Gibson
Priority: high Milestone: 1.4
Component: DojoX Grid Version: 1.3.2
Keywords: Cc: Joseph Scheuhammer, Becky Gibson, davidb
Blocked By: Blocking:

Description

URL: http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/grid/tests/test_data_grid.html

HTML div element with @id="dojoxGridMasterHeader" has @tabindex="-1" which makes it focusable and therefore it has accessible object even @role="presentation" is presented. This alters accessible of dojo grid:

grid

nothing

row

column header column header

expected accessible tree is

grid

row

column header column header

Accessible tree where intermediate accessible between grid and row accessibles is presented confuses Firefox and grid is not correctly exposed to screen readers.

Is there specific reason to make that DIV programmatically focusable which leads to accessible tree altering?

Attachments (1)

9756_9802.patch (9.2 KB) - added by Becky Gibson 10 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 10 years ago by davidb

Cc: Joseph Scheuhammer Becky Gibson davidb added

Yeah, tabindex="-1" and role="presentation" shouldn't go on the same element, ever.

Clown, can you fix this?

comment:2 Changed 10 years ago by Joseph Scheuhammer

A couple of notes:

The @tabindex="-1" attribute is present in the template (.../dojox/grid/resources/_Grid.html). If the @role="presentation" is correct, then this amounts to removing the tabindex attribute from the template, making sure that the script does not add it, and checking that removing it doesn't break anything. I suspect, however, that the tabindex="-1" is there for a reason; that something wants to put focus on the "dojoxGridMasterHeader" element. I don't know offhand what the rationale might be.

Clown, can you fix this?

Timeframe? My time is pretty much taken up by other things these days, so this won't be a priority for me.

comment:3 Changed 10 years ago by Becky Gibson

Milestone: tbd1.4
Owner: changed from Bryan Forbes to Becky Gibson

I have made a fix and posted to http://becky.dojotoolkit.org/bg091109/dojox/grid/tests/. The reason for adding the tabindex=-1 was so we could add an onblur handler to clear the selection when tabbing in/out of the grid header (I think - clown actually made the change for #6987). I have attached a patch for the curious but it also contains major changes to use activedescendant within the column headers in order to fix #9756

Changed 10 years ago by Becky Gibson

Attachment: 9756_9802.patch added

comment:4 Changed 10 years ago by davidb

@clown and @becky: wow thanks. @becky, will this change be in the next dijit release?

Alexander, you should be able to test our table stuff against the tests Becky posted.

comment:5 Changed 10 years ago by Alexander Surkov

Yes, Becky's grid looks great. At least no @tabindex, no accessible, nothing to fix on firefox side ;) Thanks.

comment:6 Changed 10 years ago by Becky Gibson

Resolution: fixed
Status: newclosed

(In [20105]) fixes #9802 refs #9756 Use aria-activedescendant to identify the column headers to a screen reader rather than setting focus to the column header. This does have some side effects with current screen readers. With JAWS 10 the column headers are spoken only the first time they are traversed. If you shift tab back to the column headers they are not spoken. Both Firefox and JAWS are being updated to better support the use of aria grid roles and aria-activedescendant so this should be fixed in future releases of those products. Also no longer puts tabindex=-1 on the ViewHeaderNode? as that inappropriately adds it to the accessibility hierarchy. Combined with the previous change, since focus is no longer going into the header nodes, the onblur handler for this viewheadernode is no longer needed to clear the focus border. !strict

comment:7 Changed 10 years ago by Joseph Scheuhammer

Note that the blur handler that was connected to the ViewHeaderNode was for FF2 only. In FF2 blur and focus events bubbled, and this handler was a way to stop the event from bubbling out of the grid.

Note: See TracTickets for help on using tickets.