- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Thu, 4 Feb 2016 17:20:13 +0000
- To: "Schnabel, Stefan" <stefan.schnabel@sap.com>, Matt King <a11ythinker@gmail.com>, 'Richard Schwerdtfeger' <richschwer@gmail.com>, 'Joseph Scheuhammer' <clown@alum.mit.edu>
- CC: 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com>, 'James Nurthen' <james.nurthen@oracle.com>, "public-aria@w3.org" <public-aria@w3.org>
- Message-ID: <SN1PR0301MB1981CFAA23799233BE40E21398D10@SN1PR0301MB1981.namprd03.prod.outlook.>
Unfortunately having a request for support doesn’t allow anybody to do anything useful with it, which goes back to the original problem. We also had a request for aria-help, which apparently is also dead on the vine. This is why the bug regarding aria-haspopup was created https://www.w3.org/Bugs/Public/show_bug.cgi?id=25851 From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] Sent: Wednesday, February 03, 2016 11:45 PM To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Matt King <a11ythinker@gmail.com>; 'Richard Schwerdtfeger' <richschwer@gmail.com>; 'Joseph Scheuhammer' <clown@alum.mit.edu> Cc: 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com>; 'James Nurthen' <james.nurthen@oracle.com>; public-aria@w3.org Subject: RE: Why is aria-expanded invalid with a checkbox? >>> It is the lack of this ability that often leads to over-complexity, such as having to add offscreen text such as “Opens in new dialog”, “Opens dialog”, “Opens in new window”, etc., which if you want actual examples of where this is being used, simply to a Google search with these phrases and you will see plenty where this is present, usually because of accessibility requirements such as these. >>> If we had a simple attribute for doing this, and if this existed years ago, fulfilling basic accessibility requirements like these would be much simpler and easier for developers to accomplish. We had one: “aria-description” was requested for symmetrical reasons (-> Matt) to aria-describedby vs. aria-label/aria-labelledby but did not manage to get to 1.1 and was shifted to 2.0 AFIK. Please correct me if I am wrong here. - Stefan From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] Sent: Donnerstag, 4. Februar 2016 08:27 To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; 'Richard Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>; 'Joseph Scheuhammer' <clown@alum.mit.edu<mailto:clown@alum.mit.edu>> Cc: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; 'James Nurthen' <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; public-aria@w3.org<mailto:public-aria@w3.org> Subject: RE: Why is aria-expanded invalid with a checkbox? “Sometimes I think we tend to overcode accessibility and overwhelm users with meta information that makes the real information harder to perceive.” I do get this, and am personally not a fan of over-complexity either. James is right though, we cannot pigeonhole behavior into the realm of screen reader users only, and there really are differences in cognition to take into account. We've all been in the situation where something that we've discussed here is so obvious that surely nobody could possibly misunderstand it, and yet it still happens regardless. I'm just talking about standard user differences, and not anything drastic. More concrete though is this, we are also not just dealing with the WCAG when applying accessibility, but we also have to factor in the legal requirements of individual clients. For the private sector this is usually a bit easier to manage, but when you also need to apply Section 508 for Federal agencies too, strict adherence starts to come into play, especially when the Federal procurement process is involved. As a simple example, this webpage lists all of the accessibility mappings that are associated with this one best practice alone: " Ensure links that spawn simulated dialogs indicate the fact" https://www.webaccessibility.com/best_practices.php?best_practice_id=887 E.G This one best practice is mapped to all of the following standards: * § 508-1194.22 Web Sites and Applications<https://www.webaccessibility.com/best_practices.php?standard_id=10> · (l) Ensure scripts are accessible<https://www.webaccessibility.com/best_practices.php?standard_id=35> * § 508-1194.31 Functional performance criteria<https://www.webaccessibility.com/best_practices.php?standard_id=40> · (a) Ensure access for blind and visually impaired<https://www.webaccessibility.com/best_practices.php?standard_id=41> * § 508-1194.31 Functional performance criteria<https://www.webaccessibility.com/best_practices.php?standard_id=40> · (b) Ensure access for low vision users<https://www.webaccessibility.com/best_practices.php?standard_id=42> * WCAG 1.0 Priority 1<https://www.webaccessibility.com/best_practices.php?standard_id=2> · 08.1 Ensure programmatic elements such as scripts and applets are accessible<https://www.webaccessibility.com/best_practices.php?standard_id=98> * JIS X 8341-3: 2004 - Technical Standards Subpart 5<https://www.webaccessibility.com/best_practices.php?standard_id=538> · 5.3 (e) Ensure user control of page updates and navigation<https://www.webaccessibility.com/best_practices.php?standard_id=552> * WCAG 2.0 Level A <https://www.webaccessibility.com/best_practices.php?standard_id=610> · 2.4.4 Link Purpose<https://www.webaccessibility.com/best_practices.php?standard_id=642> * WCAG 2.0 Level AAA<https://www.webaccessibility.com/best_practices.php?standard_id=612> · 2.4.9 Link Purpose (Link Only)<https://www.webaccessibility.com/best_practices.php?standard_id=679> * KWCAG<https://www.webaccessibility.com/best_practices.php?standard_id=688> · 4.1 - Ensure plug-ins are directly accessible<https://www.webaccessibility.com/best_practices.php?standard_id=701> * KWCAG<https://www.webaccessibility.com/best_practices.php?standard_id=688> · 4.1 - Ensure plug-ins are directly accessible<https://www.webaccessibility.com/best_practices.php?standard_id=701> · 4-1-1 - Ensure that the embedded content itself is accessible <https://www.webaccessibility.com/best_practices.php?standard_id=726> * 47 CFR 14. Advanced Communication Services<https://www.webaccessibility.com/best_practices.php?standard_id=819> · 47 CFR §14.21 Performance Objectives<https://www.webaccessibility.com/best_practices.php?standard_id=785> · (b) Accessible<https://www.webaccessibility.com/best_practices.php?standard_id=786> · (b)(1) Input, control, and mechanical functions shall be locatable, identifiable, and operable <https://www.webaccessibility.com/best_practices.php?standard_id=844> · (b)(1)(v) Operable with limited manual dexterity<https://www.webaccessibility.com/best_practices.php?standard_id=791> * 47 CFR 14. Advanced Communication Services<https://www.webaccessibility.com/best_practices.php?standard_id=819> · 47 CFR §14.21 Performance Objectives<https://www.webaccessibility.com/best_practices.php?standard_id=785> · (b) Accessible<https://www.webaccessibility.com/best_practices.php?standard_id=786> · (b)(1) Input, control, and mechanical functions shall be locatable, identifiable, and operable <https://www.webaccessibility.com/best_practices.php?standard_id=844> · (b)(1)(x) Operable with limited cognitive skills<https://www.webaccessibility.com/best_practices.php?standard_id=796> * 47 CFR 14. Advanced Communication Services<https://www.webaccessibility.com/best_practices.php?standard_id=819> · 47 CFR §14.21 Performance Objectives<https://www.webaccessibility.com/best_practices.php?standard_id=785> · (b) Accessible<https://www.webaccessibility.com/best_practices.php?standard_id=786> · (b)(2) All information necessary to operate and use the product<https://www.webaccessibility.com/best_practices.php?standard_id=845> · (b)(2)(i) Availability of visual information<https://www.webaccessibility.com/best_practices.php?standard_id=797> * 47 CFR 14. Advanced Communication Services<https://www.webaccessibility.com/best_practices.php?standard_id=819> · 47 CFR §14.21 Performance Objectives<https://www.webaccessibility.com/best_practices.php?standard_id=785> · (b) Accessible<https://www.webaccessibility.com/best_practices.php?standard_id=786> · (b)(2) All information necessary to operate and use the product<https://www.webaccessibility.com/best_practices.php?standard_id=845> · (b)(2)(ii) Availability of visual information for low vision users<https://www.webaccessibility.com/best_practices.php?standard_id=798> * § 508-1194.22 VA Testing Checklist - Web Sites and Applications<https://www.webaccessibility.com/best_practices.php?standard_id=1000703> · (l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.<https://www.webaccessibility.com/best_practices.php?standard_id=1000763> · (l.3) Is all content information of the scripted element available to a user of assistive technology?<https://www.webaccessibility.com/best_practices.php?standard_id=1000775> · (l.3.c) Do links that spawn simulated dialogs and/or calendars clearly indicate that to the user?<https://www.webaccessibility.com/best_practices.php?standard_id=1000779> * § 508-1194.31 VA Testing Checklist - Web Functional performance criteria<https://www.webaccessibility.com/best_practices.php?standard_id=1000800> · (a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.<https://www.webaccessibility.com/best_practices.php?standard_id=1000801> * § 508-1194.31 VA Testing Checklist - Web Functional performance criteria<https://www.webaccessibility.com/best_practices.php?standard_id=1000800> · (b) At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70<https://www.webaccessibility.com/best_practices.php?standard_id=1000812> * Telecommunications Act Accessibility Guidelines<https://www.webaccessibility.com/best_practices.php?standard_id=1001119> · 1193.41 Input, control, and mechanical functions.<https://www.webaccessibility.com/best_practices.php?standard_id=1001137> · (e) Operable with limited manual dexterity. Provide at least one mode that does not require user fine motor control or simultaneous actions.<https://www.webaccessibility.com/best_practices.php?standard_id=1001142> * Telecommunications Act Accessibility Guidelines<https://www.webaccessibility.com/best_practices.php?standard_id=1001119> · 1193.41 Input, control, and mechanical functions.<https://www.webaccessibility.com/best_practices.php?standard_id=1001137> · (i) Operable with limited cognitive skills. Provide at least one mode that minimizes the cognitive, memory, language, and learning skills required of the user.<https://www.webaccessibility.com/best_practices.php?standard_id=1001146> * Telecommunications Act Accessibility Guidelines<https://www.webaccessibility.com/best_practices.php?standard_id=1001119> · 1193.43 Output, display, and control functions.<https://www.webaccessibility.com/best_practices.php?standard_id=1001147> · (a) Availability of visual information. Provide visual information through at least one mode in auditory form.<https://www.webaccessibility.com/best_practices.php?standard_id=1001148> * Telecommunications Act Accessibility Guidelines<https://www.webaccessibility.com/best_practices.php?standard_id=1001119> · 1193.43 Output, display, and control functions.<https://www.webaccessibility.com/best_practices.php?standard_id=1001147> · (b) Availability of visual information for low vision users. Provide visual information through at least one mode to users with visual acuity between 20/70 and 20/200 without relying on audio.<https://www.webaccessibility.com/best_practices.php?standard_id=1001149> I’m not saying that all of these come into play at all times, but when they do, there needs to be a simple way to deal with this such as by adding a simple attribute when needed. It is the lack of this ability that often leads to over-complexity, such as having to add offscreen text such as “Opens in new dialog”, “Opens dialog”, “Opens in new window”, etc., which if you want actual examples of where this is being used, simply to a Google search with these phrases and you will see plenty where this is present, usually because of accessibility requirements such as these. If we had a simple attribute for doing this, and if this existed years ago, fulfilling basic accessibility requirements like these would be much simpler and easier for developers to accomplish. -----Original Message----- From: Matt King [mailto:a11ythinker@gmail.com] Sent: Wednesday, February 03, 2016 5:54 PM To: 'Richard Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>; 'Joseph Scheuhammer' <clown@alum.mit.edu<mailto:clown@alum.mit.edu>> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; 'Stefan Schnabel' <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; 'James Nurthen' <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; public-aria@w3.org<mailto:public-aria@w3.org> Subject: RE: Why is aria-expanded invalid with a checkbox? All modern screen readers handle focus changes into dialogs in a very graceful manner. Well designed dialogs are very easy to close, and correctly coded dialog cancellation returns focus to the element that opened the dialog. So, we have an intuitive "undo my mistake" affordance. Users do not get advanced warning of error dialogs, and they seem to handle those. In other words, I am questioning the notion that 3.3.2 dictates the user needs to be told in advance that a dialog is going to open if an element is activated. If a user would struggle with this particular behavior, it is not likely the user has any idea what a dialog is. And, I would place a large bet that such a user has no idea that "..." means that a dialog will open. So, does anyone have user testing data to suggest that we are not "creating a problem from thin air?" Sometimes I think we tend to overcode accessibility and overwhelm users with meta information that makes the real information harder to perceive. Matt -----Original Message----- From: Richard Schwerdtfeger [mailto:richschwer@gmail.com] Sent: Wednesday, February 3, 2016 11:11 AM To: Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; Stefan Schnabel <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; Birkir Gunnarsson <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; public-aria@w3.org<mailto:public-aria@w3.org> Subject: Re: Why is aria-expanded invalid with a checkbox? Ellipses are always a good indicator of a dialog box. I don’t recall seeing one on a checkbox. I could see one on a form submittal. I have seen them on pushbuttons. Rich > On Feb 3, 2016, at 1:02 PM, Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>> wrote: > > On 2016-02-03 12:28 PM, Bryan Garaventa wrote: >> I understand this in most cases, and if the group decides this is the best way to go, that's fine with me. >> >> However I do need to explain the situation, because the circumstance I'm referring to was more unique, in that the client is a financial institution that was sued because it did not adiquatly convey to non-sighted screen reader users that the checking of a particular checkbox would significantly impact there accounts, even though this was conveyed visually using CSS for sighted users. >> >> So the legal design requirements were then mandated that it must convey that something else was going to happen when this checkbox was checked. >> >> As I said, if the group decides this association is not important, I'll refer them to this thread in the future to explain why. > > The typical way to indicate that a dialog is going to be invoked is via ellipses, "...". For example, the ellipsis in a "Save as ..." menu item tells me that I'm about get a save-file dialog. I know that one screen reader, Orca, speaks "ellipsis" when one navigates to menu items with ellipses. > > Would adding an ellipsis to a check box label workl? Admittedly it looks a bit odd: > > [ ] Click to accept these terms ... > > Another thought: although it does overload the label, what about adding text to the checkbox itself, such as: > > [ ] Click to accept these terms (will show a confirmation dialog). > > -- > ;;;;joseph. > > 'Die Wahrheit ist Irgendwo da Draußen. Wieder.' > - C. Carter - >
Received on Thursday, 4 February 2016 17:20:48 UTC