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

The downside to this example is a lot of extra redundant tabstops for a 
visual keyboard-only user. This could really make the application much 
more unusable.

Regards,
James

On 8/18/2014 8:45 AM, Schnabel, Stefan wrote:
>
> Matt,
>
> I agree that
>
> <span id="s1">Staff: </span>
>
> <span tabindex="0" role="textbox" aria-readonly="true" 
> aria-labelledby="s1 s2">Smith</span>
>
> <span id="s2">(on vacation)</span>
>
> would be a better example ..
>
> For a non-blind user this looks like plain text, but the correct 
> relationship between labels and fields with data has been established.
>
> I just mention that because if you put
>
> <span>Staff: </span>
>
> <span>Smith</span>
>
> <span>(on vacation)</span>
>
> and navigate that in Jaws VPC mode (not application mode), speech 
> output is identical, but the first one forms much better relationship 
> what belongs together. In addition, in first example, the textbox is 
> listed in the Jaws form fields collection indicating that there is 
> data-bound content and allows for faster retrieval (you can debate if 
> “on vacation” is also data bound, I think add. data bound info can be 
> related as label or aria-describedby, too).
>
> This is what I meant and should be mentioned in respective guidelines.
>
> Best Regards
>
> Stefan
>
> *From:*Matthew King [mailto:mattking@us.ibm.com]
> *Sent:* Freitag, 1. August 2014 16:31
> *To:* Schnabel, Stefan
> *Cc:* Bryan Garaventa; Joshue O Connor; PF
> *Subject:* 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 <mailto:mattking@us.ibm.com>
>
>
>
> From: "Schnabel, Stefan" <stefan.schnabel@sap.com 
> <mailto:stefan.schnabel@sap.com>>
> To: Matthew King/Fishkill/IBM@IBMUS,
> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com 
> <mailto:bryan.garaventa@ssbbartgroup.com>>, Joshue O Connor 
> <joshue.oconnor@cfit.ie <mailto:joshue.oconnor@cfit.ie>>, PF 
> <public-pfwg@w3.org <mailto: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 <mailto:mattking@us.ibm.com>
>
>
>
> From: "Schnabel, Stefan" <stefan.schnabel@sap.com 
> <mailto:stefan.schnabel@sap.com>>
> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com 
> <mailto:bryan.garaventa@ssbbartgroup.com>>,
> Cc: PF <public-pfwg@w3.org <mailto:public-pfwg@w3.org>>, Joshue O 
> Connor <joshue.oconnor@cfit.ie <mailto: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 
> <http://whatsock.com/tsg/Coding%20Arena/ARIA%20Data%20Grids/ARIA%20Data%20Grid%20%28Dynamic%29/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
> >
> >
>
>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment