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).
Related
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.
Lets say, you have an image button at the UI that represents a switchable feature (i.e. tooltips on/off). What should it show according to the status (on/off). I believe, the user is expecting to see a hint for what is going to happen, when he click the button. In this case, the button displays just the opposite of the current status. For example: the two images are lightbulbs, one grey for OFF, one yellow for ON. Now, if the feature status is OFF, the button shows the yellow one, signaling that, if you click on it, the feature will be switched to ON, and vice versa. A colleague said, that this is misleading. If the feature is OFF the button should reflect this, thus displaying a grey lightbulb. I couldn't find any best practice rules for that. Anybody knows some?
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.
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.
Say I have some state which the user can toggle, for example [ON] | [OFF] .
Typically, I use ONE switch (BUTTON) and when the thing is ON, the user sees:
LIGHT IS [ON]
When it is OFF they see
LIGHT IS [OFF]
My question is: is it obvious (sensible) that one should click [ON] to turn the light [OFF]?
How do you do it? Any thoughts or ideas appreciated.
I would use a label and an button to show the action.
Light is On - Switch Off?
Clicking that would change both the label and the button to:
Light is Off - Switch On?
This solution clearly states the status and the action available.
I would definitely include the notion of a checkbox-like control if clarity is your concern. This is a widely accepted interface component, that most people understand.
In any case you can make the entire line clickable, so that it toggles when I click the text as well (just like an HTML Label element).
Showing a button with just the text 'ON' might confuse users whether it toggles the light on, or if the current state is 'on'.
An image speaks a thousand words...
Depending on the type of application, displaying a light switch image that you can click
to set the state of the field might be more intuitive?
You could then have a lightbulb-on and lightbulb-off image to show state.
Not everyone knows what a checkbox is ;)
You could use radio boxes, which are fairly standard controls and should not be confusing to most people.
<input type="radio">Light on<br>
<input type="radio">Light off
Another option is to try and implement some sort of switch button, something like this one that is used on the iPhone:
Switch button in iPhone - off http://www.poolworksbvi.com/POOL_CONTROL/Pool1_files/iphone_switch.png
Switch button on iPhone - on http://www.poolworksbvi.com/POOL_CONTROL/Pool1_files/iphone_switch+on%20copy.png