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

Stefan,

That example would fail WCAG even if the ARIA worked as you hoped with 
JAWS. Essentially, it makes the text interactive by requiring the user 
interact with it to get information. That then requires an interaction 
model that is keyboard accessible. You now have the need for an actual 
widget.

That example is essentially a mouse-only implementation of a dynamic 
show/hide pattern.

It could also be thought of as a form of the annotation pattern being 
considered for 1.1.

So, I am still wondering if there is a use case that justifies supporting 
labels and descriptions on a generic text element. All the cases I can 
think of require an ARIA role.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   "Schnabel, Stefan" <stefan.schnabel@sap.com>
To:     Matthew King/Fishkill/IBM@IBMUS, 
Cc:     Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, Joshue O 
Connor <joshue.oconnor@cfit.ie>, PF <public-pfwg@w3.org>
Date:   08/01/2014 04:34 AM
Subject:        RE: The Accessibility Tree: A Training Guide for Advanced 
Web   Development



Matt,
 
Given this:
 
<span>Members: </span>
<span title="On Vacation" aria-label="Smith: On Vacation">Smith *</span>
 
When arrowing to the line with Smith text node,  it leaves JAWS 15 with 
all defaults very “agnostic” to all the information added to the “Smith” 
span (also aria-labelledby/describedby for a span is not working when the 
span has no keyboard focus).
 
I asked myself if ARIA would be helpful here when in VPC mode. It is not 
and you have resolve this by redesign of the information:
 
<span>Members: </span>
<span>Smith</span><span>(on vacation)</span>
 
So everything is read but you are putting the info out that is otherwise 
explained in the title attribute and with the asterisk as visual clue. 
This is OK in this case, but what if the info is rather lengthy, more 
complex layout scenarios etc. etc.
 
I know that this is maybe a bit artificial example but it shows explicitly 
that ARIA properties (and title, by the way) although applicable are not 
taken/ignored by screen readers sometimes, although it would make sense.
 
Regards
Stefan
 
 
 
 
From: Matthew King [mailto:mattking@us.ibm.com] 
Sent: Freitag, 1. August 2014 13:08
To: Schnabel, Stefan
Cc: Bryan Garaventa; Joshue O Connor; PF
Subject: RE: The Accessibility Tree: A Training Guide for Advanced Web 
Development
 
what is the use case for labeling a text node in this manner? 

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com 



From:        "Schnabel, Stefan" <stefan.schnabel@sap.com> 
To:        Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, 
Cc:        PF <public-pfwg@w3.org>, Joshue O Connor <
joshue.oconnor@cfit.ie> 
Date:        08/01/2014 04:02 AM 
Subject:        RE: The Accessibility Tree: A Training Guide for Advanced 
Web  Development 




Also, I would mention and explain JAWS and NVDA behavior when trying 
things like

<span title="Howdy" aria-label="Jonas">Some Text</span>

and Jaws is NOT saying title text nor aria-label text in Virtual mode 
(since the virtual focus is on the text node)

But if we apply tabindex="0" (without indending to give a role) then the 
focus is bound to the parent and speech output will work:

<span tabindex="0" title="Howdy" aria-label="Jonas">Some Text</span>

For me it is not so clear why JAWS and NVDA when in VPC mode on a text 
node are not looking to its parent's attributes and speak acc.-relevant 
things.

Regards
Stefan

-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Mittwoch, 30. Juli 2014 16:53
To: Schnabel, Stefan
Cc: PF; Joshue O Connor
Subject: 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
>
>