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

Hi all,

yes, JAWS needs to treat role "grid" and related ones as editable. Or honor
the editable state we expose in Firefox at least for these. That's why NVDA
will work with grids by default in Firefox.

So someone with a good connection to FS should bring this to their
attention so they can fix it in JAWS.

Marco



On Wed, Jul 30, 2014 at 9:59 AM, Schnabel, Stefan <stefan.schnabel@sap.com>
wrote:

> 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 11:43:45 UTC