RE: The Accessibility Tree: A Training Guide for Advanced Web Development

Thanks, no worries about interactive support for Grid in JAWS, I've already tested this thoroughly when I was building the construct at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Data%20Grids/ARIA%20Data%20Grid%20(Dynamic)/demo.htm
If you press enter on the Grid, it will enter Forms Mode and you can arrow around as expected.

The date picker I sighted in the Application Role section though, doesn't use role=grid, but is rather a hybrid of a table including Link and Button roles to represent each active element. Since there is no interactive Widget role present, I needed to use role=application to enforce the correct behavior. 

Drag and drop is a good idea, thanks, I'll add this to my todo list. :)


-----Original Message-----
From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] 
Sent: Wednesday, July 30, 2014 1:00 AM
To: Bryan Garaventa
Cc: PF; Joshue O Connor
Subject: RE: The Accessibility Tree: A Training Guide for Advanced Web Development

Looks great. 

Limitation of role=application for certain custom elements (like date picker and navigable grids) to control Jaws behavior at these locations is a good idea since Jaws navigation behaves different in tables. The "lattice" of a grid, gridcell etc. is mapped in the platform ACC-API (to my knowledge) the same as for HTML tables (ROLE_SYSTEM_TABLE etc.):

- http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table, grid role
- http://www.w3.org/TR/html-aapi/#table-element 

I doubt that the automatic recognition of ARIA roles and subsequent navigation mode switch is currently bulletproof in Jaws and NVDA. For instance, it should not be necessary to put role="application" to the grid container. Jaws should recognize grid role and understand grid as intended to be used (a data table with active content and potentially editable cells, in opposite to "static" HTML tables with readonly content). Given this, Jaws would use "application mode" automatically for elements with role=grid (which it currently doesn't). I feel that a discussion about this with AT vendors has not yet taken place.

Nevertheless I believe you can extend this concept of "controlled behavior" to entire rich-client like UI's where you want people from start on to be in Jaws "application" mode by putting one instance of application to the <body> tag.

However, "application" became deprecated for reason in ARIA 1.1 since the people (my explanation/interpretation) felt "patronized"  by the presence of properties that directed their favor orientation mode they were used to. This is something I understand.

Maybe you can also extend this by a chapter dealing with drag and drop by keyboard.

- Stefan

-----Original Message-----
From: Joshue O Connor [mailto:joshue.oconnor@cfit.ie]
Sent: Mittwoch, 30. Juli 2014 09:15
To: Bryan Garaventa
Cc: PF
Subject: Re: The Accessibility Tree: A Training Guide for Advanced Web Development

Hi Bryan,

Wow, this looks great. Good job!

Are you ok with me passing this along to others?

Thanks

Josh

Bryan Garaventa wrote:
> Hi,
> Most of you have already seen this, but for those who haven't, this is a guide that explains the differences between the DOM and the Accessibility Tree, and how this ties into the platform Accessibility API on the OS:
> http://whatsock.com/training/
> I wanted to pass this along here in case you can think of anything else that I might have missed.
> All the best,
> Bryan
>
>

Received on Wednesday, 30 July 2014 14:53:09 UTC