- From: Matthew King <mattking@us.ibm.com>
- Date: Tue, 19 Aug 2014 17:56:47 -0700
- To: "Schnabel, Stefan" <stefan.schnabel@sap.com>
- Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, Joshue O Connor <joshue.oconnor@cfit.ie>, PF <public-pfwg@w3.org>
- Message-ID: <OF377C58E0.C940CB21-ON88257D3A.0002CB65-88257D3A.00053295@us.ibm.com>
Stefan, Remember the original question: what is the use case for putting a label on a plain text note? For example, is there a need to support putting aria-label on a span or paragraph that is not recast with a widget role? I am still not clear that we have a use case. As a screen reader user, the notion of labeling unstructured static text is not clicking with me. Semantic structure should always be sufficient. There are many ways to group related text strings so that it is easily understood from the semantic markup that a set of strings somehow go together. And, there are many ways to do it without messing up the designers ego. In your example, you could wrap your 3 related spans in a LI and give the list of people semantic structure with a UL. That would be plenty of semantic markup for a screen reader user to understand it. It would meet WCAG 2 requirements for the structure of information. The visual designer would never know. The original example given was a text node that when you mouse over, the title gives additional information. In that case, I argued that since you have a mouse event, you also need a keyboard event, and thus you have an interactive widget and should be using a widget 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: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, Matthew King/Fishkill/IBM@IBMUS, Cc: Joshue O Connor <joshue.oconnor@cfit.ie>, PF <public-pfwg@w3.org> Date: 08/19/2014 01:51 AM Subject: RE: The Accessibility Tree: A Training Guide for Advanced Web Development Bryan, this proposal (although absolutely valid) will result into a different layout scheme. More than often the visual designers have other things in mind when creating layouts and you as an accessibility consultant are typically confronted with the results AFTER implementation, and it has to be exactly as it is visually rendered. In fact, things you find often in UI's are readonly info like Id 100000002 Name DelBont Industries Street 1 2345 King Street City Wilmington, Delaware, 19899 Country US and designers don’t WANT an additional top row with headers and want visuals and EXACTLY as such. No top row, no table borders, no ":" to indicate Label, nothing. I think ARIA can help here by the method given below (without tabindex, of course). My point is here ARIA usage to address these things, nothing else. Of course you can hide the top table row in your example by CSS means (I know all this stuff) but that's another discussion. I also heard that is discriminating since then only people using screen readers will benefit from the extended info, something an example maker should always keep in mind. Best Regards Stefan -----Original Message----- From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] Sent: Montag, 18. August 2014 23:39 To: Schnabel, Stefan; Matthew King Cc: Joshue O Connor; PF Subject: RE: The Accessibility Tree: A Training Guide for Advanced Web Development I see what you mean, where ARIA is used to forcibly associate unrelated elements. The problem though, is that you can do the same thing using valid HTML markup, such as: <div> <table><tr> <th>Position</th> <th>Name</th> <th>Status</th> </tr><tr> <td>Staff: </td> <td>Smith</td> <td>(on vacation)</td> </tr></table> </div> So regarding the guide, I'm not sure it's advisable to instruct developers to use ARIA hacks instead of valid HTML markup structures, even if hacks are possible as last resorts. From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] Sent: Monday, August 18, 2014 8:45 AM To: Matthew King Cc: Bryan Garaventa; Joshue O Connor; PF Subject: RE: The Accessibility Tree: A Training Guide for Advanced Web Development 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 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 > >
Received on Wednesday, 20 August 2014 00:57:20 UTC