Is it bad accessibility practice to style a link like a button? - button

In my case, add something like className: "btn btn-default" to a react-router Link.
Like so: <Link className="btn btn-default" to={linkUrl}>Go!</Link>
Would tha tripped people who use assistive technologies to view a site?

Some general tips on when to use an <a href> versus a <button> or <input type="submit">:
If the user is going to a new page (or anchor on the page), use a <a href> (spec).
If the user is changing a state on the current page, use <button> (spec).
If the user is submitting a form, use <input type="submit"> or <button type="submit"> (spec).
I caution against changing the default role of an element with the role attribute, as that can ultimately cause some confusion and potentially conflict for some assistive technology. These also violate the first and second rules of ARIA use.
Consider the keyboard experience as well. A hyperlink (<a href>) can be fired by pressing the enter key. But a true <button> can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. Users of some assistive technology will expect behavior based on the element used.
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
So start with the right element for the task using the list above, then style it to look however you want.

tl;dr best practice is to make things look like they act but you may not have the luxury, so now what role should the element have?
You should style and role your links and buttons so they communicate this to the user. This is general good usability practice.
However, that only works in a world in which branding and marketing people don't have any say. Have you ever heard the argument "we need to make that link more prominent so visitors click on it more..." This is where links start turning into these monsters that are no longer identifiable by how they look AND act.
So now you have stumbled on one of the great debates of accessibility: should something have the role that matches how it behaves or should it have the role that matches how it looks?
A link is an element that directs the browser to another location (either another page, or another location on the same page). This is how it was designed.
Buttons on the other hand are designed to interact with the page or submit data.
The complication is, when you have a link that looks like a button and a blind user phones support and the support person says "click the X button" and the screen reader announces Y link (because the text alternative for the button is wrong), then the blind user gets really frustrated because they can neither find a button nor something that matches the X.
However, if you are trying to do accessibility the right way and your link text matches the visible information for the element, then IMO you should always have a role on the element that matches the way it behaves.
In your specific example, someone using a speech recognition system like Dragon would have difficulty clicking the link because they might use a command like "buttons" to list all the buttons and not see the element they are expecting. This user would then have to guess that it is in fact a link, or use mouse targeting to interact with the element.

The points raised by aadrian and unobf above are accurate and well stated. There is still another reality which cannot be avoided that forces the developer's hand.
Designers frequently deemphasize one or more actionable element in a group, a delete button for example, because it is used less frequently or catastrophic if used in error. Research suggests catastrophic errors can be reduced using this strategy.
Since many seasoned professionals demand that the markup for the control matches the presentation, the developer's first instinct may be to mark up the delete control as a link.
Assistive technologies for the visually impaired such as Jaws rely on lists of controls of a single type. Surveys indicate this strategy is utilized by the visually impaired fairly frequently.
With these accessibility realities in mind, it is a very bad practice to mark up a list of actions as some buttons with one or more links for actions such as delete. The visually impaired user will likely not associate the link with the buttons and may miss the link entirely.
This reality essentially forces the developers hand. If the design calls for a delete link in a list of buttons, the developer must mark up the link as a button, even though the keyboard navigation will not align perfectly for the sighted user.

Related

What accessibility pattern for filter/sort "dropdown"?

I have a design that displays a list of content that you can filter by different categories. Each filter is displayed in a dropdown menu that lets you choose one or more options, which when activated (either through click or keyboard), will update the results on the page. The page url does not change in response to the filter and there is no "submit" button to apply the filter.
I'm confused which ARIA pattern to use: Menu (with menu/menuitem roles) or Combobox (with listbox/option roles).
In my opinion you should go with a combobox.
Otherwise, it should be a menubar rather than menu:
A menu that is visually persistent is a menubar.
Managing focus
Aside from the question which role to use, you need to decide whether to manage focus or not. It is recommended (should) for menu and menubar, which would mean that the whole bar only has one tab stop, and navigation between the single dropdowns is done via arrow keys.
Website or application?
This depends on how much your site feels like an application overall. If it’s more of a website, keyboard users in general are more accustomed to tabbing than to managed focus. For users it is sometimes a surprise that you need to navigate within components by means of arrow keys.
If there are other composite widgets as well that manage focus, you absolutely could do so for this part as well.
Responsive Design
A menubar should allow left and right arrow keys to navigate the filters, and up and down to focus the options. Managing focus would get complicated with Responsive Design: Once items wrap, it becomes less obvious how to navigate to them.
Actions vs Selections
A menu is usually used for actions. To quote some references (emphasis mine):
A menu is a widget that offers a list of choices to the user, such as a set of actions or functions.
– Menu or Menu bar pattern
The WAI ARIA standard defines an actual `nole="menu"' widget, but this is specific to application-like menus which trigger actions or functions.
– Bootstrap
Since the filters only allow choosing options, and not executing commands or functions, I would rather go with combobox.
Searchability
Combobox also implies that it’s a flat list of options, maybe grouped. This is immediately known. A menu can potentially have sub menus, so it’s less clear what to expect when opening a filter list.
Since combobox is a flat list, users can type Printable characters to directly jump to a list item. This is not the expectation for menus.
Show the user’s selection
Since the filters close once a selection is made, it is best practice to display the chosen value or values in the closed item. Also known as the Visibility of System Status.
A combobox will do so, and screen readers would even announce the current choice without opening the list. A menu does not have that behaviour.

ARIA for Multi-State Toggle Button?

I have a button that cycles through states on click: {off, red, blue, green}
Desired behavior would be:
When first focusing the button it announces something like: "My button, Green"
When clicking the button it announces only the state, like: "Red"
Any advice on how to achieve this?
It can be difficult to make a user interface that isn't "common" to be accessible. For sighted users, is there a visual clue that the button has four states and that clicking on it, rather than performing an action, actually changes the state of the button?
This is often done with a "segmented button" that shows all the states possible and you click on the appropriate state you want. Very similar to a radio group. (The URL links to Apple's Human Interface Guidelines but the same concept can be used for web.)
You can potentially use aria-roledescription to describe how your widget will function rather than having a basic "button" role announced.
To manage what is actually announced, you could have complete control of what is spoken by the screen reader by having an aria-live region. I've posted on live regions several times recently so I'll just point to one of my previous answers (which in turn has links to a few other answers on live regions).

Make screenreader say button alt-attribute instead of innerText

Is it possible to force a screen-reader to read the alt-attribute instead of the text inside a button?
Example html: <button alt="user menu">DrKawashima</button>
When testing this with the built-in accessibility screen-reader in MacOS, I found that it only said "DrKawashima", and the alt-attribute was never used.
Is there a way to hint to screen-readers that I would rather have it say "user menu"?
Yes, it's possible - but beware of completely overriding the visible text of a button.
tl;dr - I recommend approach 4 here.
Your question addresses screen readers, but there are other types of assistive technology to consider. In particular, sighted people using speech control (e.g. Dragon Naturally Speaking). Take care to address WCAG Success Criterion 2.5.3: Label in Name.
Assistive technology deals with the computed accessible name of an element:
Screen readers will read the computed accessible name. Remember that the basic purpose of of a screen reader is to read what's on the screen - beware of trying to present a different interface to screen reader users.
Confusion can arise when a blind screen reader user and a sighted person are both talking about the same screen. For example, a telephone tech support person might say "Click on the button which says DrKawashima". But if this is overridden, the screen reader says the button is called "User menu", and the user can't find the button they're being told to press.
Sighted people also use screen readers. For example, someone with dyslexia may like to have stuff read out to make life easier. When the computed accessible name differs from the visible text, the screen reader is effectively lying to the user about what it says on the screen.
Speech control will try to match what a user says, to the computed accessible name. If a button has visible text, it's important that this text appears inside the computed accessible name of the element. The expectation is that a speech control user can activate a button by saying the visible text. In your example, saying "Click DrKawashima" should activate the button. This won't work if the computed accessible name is "User menu".
There's a work-around for this. Dragon Naturally Speaking has a tool to highlight all buttons using numbers: say "Click button", look for the number, then say "Choose 2". However this is a multi-step process, requiring extra effort from the user.
Note that the computed accessible name and the visible text do not have to match exactly. Rather, the visible text must form part of the accessible name.
Let's look at some examples:
Your example with an alt attribute on the button simply won't work, because buttons don't have an alt attribute. This isn't valid HTML:
<button alt="user menu">DrKawashima</button>.
The visible text is "DrKawashima"
The computed accessible name is "DrKawashima". The alt attribute had no effect.
This passes WCAG "Label in name", because the visible text and the computed accessible name are exactly the same.
However it doesn't manage to inform a screen reader user about the purpose of the button; sighted users can probably infer this from an accompanying icon or avatar image.
The aria-label attribute can be used to completely over-ride the button content: <button aria-label="user menu">DrKawashima</button>.
The visible text is "DrKawashima".
The computed accessible name is "User menu". The aria-label attribute completely overrides the button content.
This approach FAILS WCAG "Label in name", because the visible text doesn't form part of the accessible name. A speech control user can't activate the button by saying "Click DrKawashima".
The aria-label attribute can be used to completely over-ride the button content, whilst duplicating the visible text: <button aria-label="DrKawashima, User menu">DrKawashima</button>.
The visible text is "DrKawashima".
The computed accessible name is "DrKawashima, User menu". The aria-label attribute completely overrides the button content, but it duplicates the visible text.
This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
This approach is simple, but may be fragile because you have to manage two strings.
Include some visually-hidden text, to give screen reader users some additional context. For example, using HTML5Boilerplate's .visuallyhidden class, or Bootstrap's .sr-only class:
<button>DrKawashima<span class="visuallyhidden">, User menu</span></button>
The visible text is "DrKawashima"
The computed accessible name is "DrKawashima, User menu". This results from the button content.
This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
This is the simplest solution, very robust.
The aria-labelledby attribute can build an accessible name, by referencing 2 element IDs:
<button aria-labelledby="user-menu-visible-label user-menu-suffix"><span id="user-menu-visible-label">DrKawashima</span><span id="user-menu-suffix" class="visuallyhidden">, User menu</span></button>
The visible text is "DrKawashima"
The computed accessible name is "DrKawashima, User menu". This results from concatenating the two elements refernced by aria-labelledby.
This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
This is robust, but a bit more work to implement because you need to manage the ID references.
'alt' is not an allowed attribute within a button element. The alt attribute works with area, img and input type="image". Check out more on the topic https://www.w3.org/TR/html5/dom.html#translatable-attributes and https://www.w3.org/TR/html5/dom.html#global-attributes-2
Your best bet is to use a styled <span> tag inside the <button> with aria-hidden
<button aria-label="screen reader text">
<span aria-hidden="true">Visual Text</span>
</button>
Edit: As discussed in comment this isn't the best approach.
As a speech control user can't activate this button.
andrewmacpherson's answer provides a more inclusive solution to this.

Custom behavior with radio buttons and/or checkboxes. Accessibility ( WCAG 2.0 )

I want to reveal some hidden text/elements(whatever) when some checkboxes/radio buttons are selected(assume there is a list of checkboxes/radio buttons to choose from).
What should I do to meet the WCAG 2.0 AA standards?
And how exactly radio buttons/checkboxes are understood by AT users, because obviously this isn't the supposed behavior of checkboxes/radio buttons.
Thanks!
Your last statement gives me pause: "And how exactly radio buttons/checkboxes are understood by AT users, because obviously this isn't the supposed behavior of checkboxes/radio buttons."
If you have non-standard behavior for your radios/checkboxes, will the sighted user be confused too?
With 'normal' behaving radios/checkboxes, the AT user will understand them just like a sighted person does - experience. You learn that a radio is a group of mutually exclusive choices whereas a list of checkboxes allows multiple choices. The screen reader will read the role of the object so the AT user will know what to do.
Now, if you're hiding/unhiding objects based on those selections, the AT user needs to be notified. That's typically done with aria-live. By default, an aria-live region will be read if the text changes or an object is added to the DOM which should include being unhidden if you're doing it via display:none. If you unhide by moving an offscreen object to onscreen, or changing the clipping rectangle, or changing the size of the object, aria-live will not help.
Also look at aria-relevant. By default, it's value is 'additions text', which is the behavior I mentioned above. If you need the aria-live region to be read on other conditions, look at the other values of aria-relevant.

Should I use Button or TextBlock?

I have two options. I need 48 of a certain type control; it needs to respond to clicks and taps (for touch devices).
I could use Buttons, using the TextButtonStyle, and the Click event. Or I could use TextBlock, with the Tapped event.
I reckon buttons may be more "expensive" to create. OTOH, although I believe "Tapped" is also called when the user clicks the component, this makes me a little nervous due to its nomenclature, I guess.
Another difference is that a button takes up only the width necessary, whereas a TextBlock takes everything; and I want the underlying Grid to be tappable, so the TextBlock is kind of a problem that way. Is there a property that will make it more modest like the button?
There is design guidance for Windows Store apps on when and how to use buttons at http://msdn.microsoft.com/en-US/library/windows/apps/hh465470. Based on your description and this guidance, it sounds like buttons are the way to go. Responding to click events is what they were made for, and TextBlocks add the extra issues that you describe.

Resources