- From: David MacDonald <david100@sympatico.ca>
- Date: Mon, 18 Jul 2016 18:34:34 -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: <BLU437-SMTP21761F1EE3585E27FD0DDDFE360@phx.gbl>
Sounds like we have consensus "WCAG 2.1 will not make any additional requirements on buttons and links keyboard triggering other than those already in WCAG 2.0" 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 4:33 PM, David MacDonald <david100@sympatico.ca> wrote: > 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 22:35:07 UTC