E-mail List Archives

Thread: Actionable roles vs behaviors

for

Number of posts in this thread: 1 (In chronological order)

From: Sailesh Panchang
Date: Mon, Jul 17 2017 10:59AM
Subject: Actionable roles vs behaviors
No previous message | No next message

I have one question that this thread does not seem to answer: Is
styling a link to appear like a button a WCAG 2.0 failure?

With reference to the words 'edge case', I think if, say, 3 users
visually identify an element as a button and 2 other users identify it
as a link, it is an edge case.
If generally users identify an element as a button based on its
appearance, then I suppose the designers / developers intended it to
be a button and should have used the proper semantic markup.
Marking it up as a link fails SC 1.3.1 IMO. See failure F43 and test procedure:
"Check that the element's semantic meaning is exposed to assistive
technology and appropriate for the content of the element".

If the 'Submit' element appears like a link and is marked up as a
link, there is no accessibility problem. It is a design / usability
problem at best.
In addition to the use case of a blind user on the phone with a
support staff person, consider:
I suppose most users expect a button to be present at the end of the
form to submit it.
While mouse users can quickly navigate to and click the submit button,
a screen reader user cannot use te 'B' key to get to the button if it
is marked up as a link but is styled like a button. Nor can one use
the rotor to find the button on an iphone.
This is important for a long form or an application consisting of
several steps like a tax form etc.
Or when one corrects an error in a field near the start of the form
and has to tab several times to get to the submit button. As other
have stated this impacts efficiency significantly.

With reference to: "Though I think we exaggerate the importance of an
element's ssemantic role, nevertheless users of
assistive technologies rely on those to a much larger extent than
"regular" users":
While I agree with the latter part of this statement I do not think
there is any exaggeration in expecting correct semantic markup. That's
the whole point of accessibility and SC 1.3.1, "Info, relationships
and structure conveyed through presentation can be programmatically
determined".

Do we not fail text that appears and functions like a section heading
but is not marked up as a heading?
So if an element is styled and functions like a button but is not
marked up as one, is it not a failure?
Maybe an explicit example of this should be added to failure F43.
Thanks and best regards,


On 6/21/17, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 21/06/2017 12:50, Karl Brown wrote:
>> I'm in the camp of "button does a thing, link goes to a place,
>> input=submit
>> sends a thing" myself, but I can see the argument for calling something
>> that looks like a button a button.
>>
>> I have had the conversation with designers, and we've actually settled on
>> calling things a *call to action* rather than a *button*. This way the
>> designers aren't telling the developers "this is a button" - rather
>> they're
>> saying "this is a primary call to action" and the developers have a bit
>> more freedom to decide on whether to mark it up as a link or a button (the
>> junior developers will usually ask, and the senior developers have the
>> same
>> ideas I do so far).
>>
>> I think for the use case Jennifer pointed out it comes down to the script
>> a
>> training document or call centre colleague uses. I try to steer away from
>> "use the red button" or "click the *pay* button" by writing the script as
>> "choose *pay*" with a screenshot if it's for training, or "choose *Pay* -
>> it's under the list of items in your basket".
>>
>> I'll admit I've been lucky and not found a use case that I couldn't
>> rephrase my way out of, yet. Sometimes the right choice of words saves a
>> lot of headaches.
>
> Echoing this from Karl. Well put. (I've stayed out of the discussion on
> list, but had a bit of a tweetstorm last night anyway on the topic)...
> https://twitter.com/webaim/status/877294402217037824
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765