- From: David MacDonald <david100@sympatico.ca>
- Date: Mon, 18 Jul 2016 16:33:35 -0400
- To: WCAG <w3c-wai-gl@w3.org>
- CC: Jonathan Avila <jon.avila@ssbbartgroup.com>, John Foliot <john.foliot@deque.com>, "White, Jason J" <jjwhite@ets.org>
- Message-ID: <BLU436-SMTP5304A8F41DEB15EB0402DFE360@phx.gbl>
The page is linked from WCAG 2.1 not the current WCAG. I'd never fail a link as a button in WCAG 2. It just needs to work with keyboard. It doesn't even need the enter key to activate. It could be some other keyboard activation under WCAG 2. The exploration of this issue is about WCAG 2.1. I don't have a strong opinion about whether WCAG should be modified in this way, but it is an area that is being actively discussed in accessibility and usability circles and this is the time to explore what goes in and what doesn't go into WCAG 2.1, so I think we'd be remiss if we didn't discuss it. We have 5 months to agree on what we want in WCAG 2.1... Cheers, David MacDonald *Can**Adapt* *Solutions Inc.* Tel: 613.235.4902 LinkedIn <http://www.linkedin.com/in/davidmacdonald100> twitter.com/davidmacd GitHub <https://github.com/DavidMacDonald> www.Can-Adapt.com <http://www.can-adapt.com/> * Adapting the web to all users* * Including those with disabilities* If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html> On Mon, Jul 18, 2016 at 1:48 PM, John Foliot <john.foliot@deque.com> wrote: > +1 to Jonathan and Jason. > > I continue to struggle with using Failure Techniques to "define" Success > Criteria - it just feels wrong and off to me, as there are so many ways to > 'fail' that I struggle to see the value in documenting them all. Further, > as Katie previously pointed out, this WG had to go back and clarify that > Techniques are non-normative - a point we should be re-enforcing, not > slipping-on by referencing them as part of the defining of a SC. > > For example, David references: > > Failure of 2.1.1 due to using a link for a button without trapping > spacebar to activate button > > This is only a failure when you have an actual keyboard that has a > spacebar - and lots of devices today don't have (nor expect) keyboards. So > I cannot "Fail" a webpage simply because a button cannot be activated by a > spacebar, because that's NOT what the Success Criteria calls for; it calls > for "All functionality <https://www.w3.org/TR/WCAG20/#functiondef> of the > content is operable through a keyboard interface > <https://www.w3.org/TR/WCAG20/#keybrd-interfacedef> without requiring > specific timings for individual keystrokes, except where the underlying > function requires input that depends on the path of the user's movement and > not just the endpoints. (Level A)" The keyboard interface is defined as > "...interface used by software to obtain keystroke input...", and as > Jason notes, "...the “standard keys” tend to be operating system > dependent.", so I am somewhat lost with the point David is trying to make: > there is nothing in WCAG 2.0 that mandates using a spacebar. > > Calling out the desire to *also* make a pseudo button operate like an > actual button w.r.t. spacebar is a best practice in my opinion - as Jon > notes, as long as there is an accessible means to activate the "button" > then it meets the technical requirement. Anything above and beyond that > is usability/best-practice territory IMHO. > > JF > > > > On Mon, Jul 18, 2016 at 12:14 PM, Jonathan Avila < > jon.avila@ssbbartgroup.com> wrote: > >> Ø Failure of 2.1.1 due to using a link for a button without trapping >> spacebar to activate button >> >> >> >> SC 2.1.1 does not require that all keystrokes work – but that there be a >> way to operate something. If enter activates the link that looks like a >> button then IMO it would not fail the current SC 2.1.1. We would certainly >> advise and recommend supporting the standard keystrokes and roles but >> failing this under the current WCAG seems to go beyond the requirements. >> >> >> >> Jonathan >> >> >> >> *From:* David MacDonald [mailto:david100@sympatico.ca] >> *Sent:* Wednesday, July 13, 2016 4:25 PM >> *To:* White, Jason J >> *Cc:* WCAG >> *Subject:* Re: Should WCAG2.1 provide requirements or guidance on >> buttons vs. links? >> >> >> >> There are two possible failures under 1.3.1 and 2.1.1 that occur to me. >> >> >> >> · Failure of 4.1.2 due to using a link as a button, without a >> button role. >> >> · Failure of 2.1.1 due to using a link for a button without >> trapping spacebar to activate button >> >> >> Cheers, >> David MacDonald >> >> >> >> *Can**Adapt* *Solutions Inc.* >> >> Tel: 613.235.4902 >> >> LinkedIn >> <http://www.linkedin.com/in/davidmacdonald100> >> >> twitter.com/davidmacd >> >> GitHub <https://github.com/DavidMacDonald> >> >> www.Can-Adapt.com <http://www.can-adapt.com/> >> >> >> >> * Adapting the web to all users* >> >> * Including those with disabilities* >> >> >> >> If you are not the intended recipient, please review our privacy policy >> <http://www.davidmacd.com/disclaimer.html> >> >> >> >> On Wed, Jul 13, 2016 at 3:34 PM, White, Jason J <jjwhite@ets.org> wrote: >> >> >> >> >> >> *From:* David MacDonald [mailto:david100@sympatico.ca] >> *Sent:* Wednesday, July 13, 2016 10:02 AM >> >> Phil Jenkins has called us to provide greater clarity on the issue. >> >> https://lists.w3.org/Archives/Public/w3c-wai-ig/2016JulSep/0038.html >> >> *[Jason] A clear proposal emerging from this would be to hold that >> “identified consistently” in sc 3.2.4 encompasses having the same role – >> both in the presentation and in what can be programmatically determined, as >> well as the same icon, label or other means of identification.* >> >> *Are there other proposals arising from this discussion?* >> >> >> ------------------------------ >> >> This e-mail and any files transmitted with it may contain privileged or >> confidential information. It is solely for use by the individual for whom >> it is intended, even if addressed incorrectly. If you received this e-mail >> in error, please notify the sender; do not disclose, copy, distribute, or >> take any action in reliance on the contents of this information; and delete >> it from your system. Any other use of this e-mail is prohibited. >> >> >> >> Thank you for your compliance. >> ------------------------------ >> >> >> > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > john.foliot@deque.com > > Advancing the mission of digital accessibility and inclusion >
Received on Monday, 18 July 2016 20:34:08 UTC