Re: Should WCAG2.1 provide requirements or guidance on buttons vs. links?

+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