Our Design System wants primary buttons on the right, secondary buttons on it's left. This is especially great if the primary button will continue to the next step of the form.
At the same time our accessibility guidelines want focus to jump to the primary button before the secondary buttons, which seems legit as well.
Does anybody have some test results whether this is terribly irritating to keyboard users?
We could use flex-direction: row-reverse to implement it.
.button-group {
display: flex;
flex-direction: row-reverse;
}
.button-primary {
font-weight: bold;
}
<form>
<label>
Last input of form
<input type="text" />
</label>
<p class="button-group">
<input type="submit" value="Continue" class="button-primary">
<input type="button" value="Save" class="button-secondary">
</p>
</form>
There is nothing wrong with focusing the primary action before the secondary action here.
People often misinterpret WCAG 1.3.2 to mean that every item on a page must exactly follow the DOM order.
It is a little more nuanced than that. What 1.3.2 covers is that you must not change the meaning of the page. So if you had a block of text and used absolute positioning to reorder that text visually this would break the ordering for someone using a screen reader.
If you look at Understanding 1.3.2 guidance you will see an example that may surprise you and is semi-related to what you are doing:
Examples of Success Criterion 1.3.2 - Example 2: CSS is used to position a navigation bar, the main story on a page, and a side story. The visual presentation of the sections does not match the programmatically determined order, but the meaning of the page does not depend on the order of the sections.
As you have correctly identified the buttons so that pressing enter does submit the form (type="submit" and type="button" respectively) the expected behaviour is there for keyboard users anyway.
The only thing I would point out is that a lot of people who use a screen reader still use internet explorer, so perhaps have a fallback style sheet that uses float: right here that is conditionally loaded for IE as support for flex is not good in IE.
This actually the correct implementation. I did something like this in one of my project on Modal window and was much liked by client as well as user.
Related
(This question is similar to Should ARIA labels provide context?, but not identical, as I'm talking about buttons and do not have full control over the markup.)
I have some amount of items and buttons that act on those items. Here's a simplified example:
<ul>
<li><span>Item: foo</span> <button>remove</button></li>
<li><span>Item: bar</span> <button>remove</button></li>
<li><span>Item: baz</span> <button>remove</button></li>
</ul>
As far as I understand, when someone using a screen reader tabs through the page, they will be read the button text but not the item text. This doesn't seem ideal to me, as they don't have context on which item the button will remove.
Assume that I don't have full control of the markup; I can only add attributes.
What is the best practice in this situation?
add an aria-label to the button that gives more context:
<button aria-label="Remove item foo">remove</button>
make the item text itself tabbable and give it an aria-label so it's read aloud:
<span tabindex="0" aria-label="Item foo">Item: foo</span>
leave things as they are, because this is intended behavior and/or I'm misunderstanding something about screen readers
something else entirely?
The answer depends on if you're trying to conform to the Web Content Accessibility Guidelines and are only worried about compliance issues (from a legal perspective), or if you want to have a great user experience regardless of whether you conform or not.
The first part, conformance, is a little tricky. Regarding context, 2.4.4 Link Purpose (In Context) comes into play but only for links. The guideline says the text for a link is ok if the user can figure out the meaning of the link from the link text and the surrounding context (such as what text is before or after it). And then context is defined as the link being in the same list item (<li>) as the surrounding text.
So that sort of fits your scenario, but you have buttons instead of links, so WCAG 2.4.4 doesn't really apply to you.
There isn't a clear guideline for the context of buttons except WCAG 2.4.6 Headings and Labels. It says that the label [of a button] must describe the purpose of the button. So who decides whether the label is descriptive enough? That's a tough call. Is "remove" descriptive enough? Maybe, maybe not. It kind of depends who you ask.
So if you are focusing on a great user experience rather than conformance to WCAG, adding context to the buttons is a really good thing.
You are correct that if a screen reader user tabs through the interface, they will only hear the button label and not the list context. But screen reader users have many ways to navigate a webpage. One option is to navigate by list elements (<ul> or <ol>) by using the L key (JAWS and NVDA). Another is to navigate by list item (<li>) by using the I key. (That's the letter 'i', not a number 1). So a user can navigate to your list items, hear the text of the list and the text of the button and get some context.
I would not recommend your second idea of adding tabindex to the list. You don't want the user to tab to elements that are not interactive.
Adding more context via a label is the best approach. I would recommend using aria-labelledby before resorting to aria-label. If you have an element in the DOM already that has the text context you need, give that element an ID and then refer to that ID in the aria-labelledby of the button. It's a little more work but then you don't have to worry if you change the text in the list because the button is using an indirect reference and will automatically pick up the new text.
You'll also need an ID on the button and then you have the button point to itself and to the context. That sounds confusing but here's all it is:
<ul>
<li>
<span id='item1'>Item: foo</span>
<button id="button1" aria-labelledby="button1 item1">remove</button>
</li>
<li>
<span id='item2'>Item: bar</span>
<button id="button2" aria-labelledby="button2 item2">remove</button>
</li>
</ul>
A simpler approach is to use aria-label as in your first suggestion but I don't like repeating text in an aria-label that's already in the DOM. If your list text changes at some point, you have to remember to change the aria-label too.
Making the span focusable is a very bad idea unless it produces an action itself when clicked. Only elements that are actually interactive should be focusable.
It's very confusing for the user is something is focusable but don't provide any interaction when focused.
Adding context with aria-label is a good idea, but in fact there is better.
The recommended way is to add off-screen text instead:
<button>Remove <span class="sr_only">Item 123</span></button>
Where .sr_only is a CSS class present in many frameworks with different names (sr_only, visually-hidden, etc.) which send the text off-screen. It is invisible for normal users, but read as normal by screen readers.
I am building an app which has to be WCAG compliant. It requires about 12 buttons. Some of the buttons have only tooltips and icons but no labels. I haven't been able to find clear cut language in WCAG about this problem. Are titles necessary for buttons?
Short answer
Yes, your button must have so form of text label associated with it.
But don't be confused with <label>, which is normally unneeded for a button.
Long answer
The answer isn't answered directly in WCAG, but this is a question of perception, which is the first WCAG core principle.
If your button has only an icon but no alternative text or label, it follows that screen reader users won't perceive your button.
So, in the broad sense, yes, your button must have a kind of label.
You have several ways to set an accessible label, technically known as accessible name, to a button having no text itself:
Attribute alt of <input type="image"/> or the <img/> which is inside the button
aria-label or aria-labelledby attributes
Visually hidden text
Don't be confused with <label> element. It's unneeded for a button, since a button usually carry its own accessible name.
An <input type="text"/> need a separate <label> because it has typically no accessible name otherwise.
This may also be a question of understandability, which is the second WCAG principle.
Even for perfectly sighted people, are you sure that the meaning of your button without any text is crystal clear ? Few icons are known to be almost universally understood by everybody without any hint, any help, any tooltip, nothing.
IN that quite small list you can certainly find multimedia buttons (play/pause/stop/record), parameters/settings wheel, power on/off, but probably not many more.
As a consequence, the question isn't only about having an accessible name for screen readers. It goes much beyond that.
To wrap up, yes, your button definitely must have some form of text label associated with it.
Short Answer
You should add aria-label to your buttons.
Longer Answer
Buttons need a name that can be computed for accessibility. First to answer your questions:
Are titles necessary for buttons?
No
Should buttons have labels from WCAG point of view?
No once again, in fact they are probably not valid.
So what should I do?
Buttons don't need titles or <label>s (in fact a <label> on a button would probably not be valid without some WAI-ARIA).
But, they do need to have an accessible name, and I think this is the part that is causing confusion.
Because your buttons only have an icon and a tooltip, they probably / possibly do not have any text that is useful to assistive technology (such as a screen reader).
So when they reach a button with just an icon using a screen reader they will hear "button", with no indication of what the button is for!
The fix
There are several ways to approach this, but the easiest is aria-label.
WAI-ARIA is a set of attributes you can add to HTML elements to add extra meaning / semantics to make a page make more sense to assistive tech users.
The aria-label attribute, when used on an interactive element (such as a button, an anchor / hyperlink etc.), will indicate the the browser "hey, please present this as the accessible name for this element.".
So in your example, something similar to the following would ensure that the purpose of a button is clearly described:
<button aria-label="Add New Document">
<!-- your icon -->
</button>
So instead of just saying "button" when focused it will now say "Add New Document, button".
Intro:
I'm coding a single-page app. It's a sort of e-book reader and I want to optimize screen reader experience.
For general performance reasons (load times, HTTP requests) all of the functional components of the app are always present in the DOM, visibility managed by CSS. Only the actual content is dynamically loaded.
That means there's a lot of stuff present that is not needed all the time, e.g. the login/register pages.Sighted users won't know, but screen reader users could be annoyed.
There's also things that I figure shouldn't matter to screen reader users, like a bunch of visual options (font size, colors...).
What I intend:
I want to hide certain sections by applying aria-hidden="true".
I want to dynamically apply that to elements which are not currently functional, like the register page for a logged in user.
Also, I want to generally hide certain "presentational" sections, like visual options.
Questions:
Is that good practice?
Are there drawbacks?
Is it necessary?
Are there other/better ways of telling sr users that elements are of no use to them?
and, last no least,
Are there good ways of directing the attention of sr users to certain elements?
-
p.s. I have already structured the DOM sensibly, like
<body>
<main role="main"></main>
<nav role="navigation">
<button>Next Page</button>
<button>Previous Page</button>
...
</nav>
<menu role="menu">
<ul>
<li><button role="menuitem">Important Task</button></li>
...
<li><button role="menuitem">Least Worthy Task</button></li>
</ul>
</menu>
<div class="options">
...
</div>
to make sure that the controls should be tab-focused in descending order of use frequency.
I assume that the act of changing page would remove/hide the current content and unhide the new page? In which case it sounds like you are taking a good approach from a showing/hiding point of view.
I did a quick gist / cheat sheet recently of current best practice for: hidden from all, hidden from screen readers, or shown only to screen readers:
https://gist.github.com/alastc/7706437
For items which are currently not active but disabled, it might be inconsistent (and therefore confusing) to hide them? Perhaps use the disabled/aria-disabled attribute instead.
As the content and next/previous are first in the order, having several disabled controls after those should be fine. NB: When reading screenreaders have a 'browse' order that follows the DOM and is not affected by tabindex. You're order looks good, so don't try and over-ride it with tabindex.
Also, please pay attention to keyboard focus. I.e. when you select 'next', does the keyboard focus move to the top of the next page? I wrote an answer about the keyboard focus aspect for single-page apps.
Also, as you have multiple nav elements it would be helpful to label them, then they could be announced as "Page, navigation" and "Options, menu" (for example).
Take a look at the following link. It lists ways to hide content from screen reader users as well as what combinations of screen reader and browsers behave properly.
http://www.html5accessibility.com/tests/hidden2013.html
Your approach will work however you are over thinking things.
Any content hidden in CSS with display: none or visibility: hidden is also hidden to screen readers
When I am hovering over an HTML label the mouse pointer changes to a hand image which we generally get when clicking a link. How can I avoid that?
The reason why you might get a hand cursor in some browsers, is because one of the main purposes of a label element in most browsers is to provide a clickable description for a form input element. For example, this is a typical use of the <label> element:
<input type="checkbox" name="TermAgreement" id="TermAgreement" />
<label for="TermAgreement">I agree to these terms</label>
In most browsers, this will result in the text "I agree to these terms" being clickable. When you click on the text, it will toggle the checkbox with an ID of TermAgreement, just as if you had clicked on the check box itself.
(Note: The W3C specification for <label> in HTML 5 doesn't require this behavior, but it does say that the browser's implementation of <label> "should match the platform's label behavior". In practice, this usually means <label> elements are clickable.)
So essentially, the cursor behaves as though the <label> is a link because it is a link, of a sort. If you're using it differently, you might want to consider using a different HTML element instead.
Whether or not a particular user sees a hand cursor when mousing over a label will vary depending on their OS and browser. Chrome and Firefox aren't displaying this behavior for me on Windows XP, but other platforms might. Also, it's possible that you have a CSS file included which specifically calls for this behavior. There would be a rule in your CSS that looks something like this:
label {
cursor: pointer;
}
If you want to override the element's default behavior, you can use cursor: default; in your CSS, as #rickyduck said. You can find information on the CSS cursor property here. Note that changing the cursor will not necessarily mean the element won't respond to being clicked.
If this doesn't solve your problem, please provide us with more information. Sample code, the URL of the page displaying the behavior, as well as which browser you're using would also be good to know.
<label style="cursor:default">Text<label>
Basically, having multiple forms in a row isn't possible so far as I've seen.
LastUpdate
Given the situation with phones and
the unpredictable nature of how most
the browsers render the page, I think
I have to go with multiple buttons per
form. Not super happy with this since
it feels like a WebForms hack for MVC
but it makes the most sense for the
situation. Making a complexish ui for
mobile devices is tough in WebForms,
looks to be harder in MVC.
Something I've been reintroduced to is the idea of having multiple forms per page so that you can have buttons post to different controllers. Problem is that turns out a form is a block element so that it's not possible to get to button next to each other. (Why they are block elements I'd like to know.)
Now here's the main problem, this is a site that was build to be viewable on most phones with a browser. It also has a lot of buttons due to buttons being a lot easier to click with touch phones like iPhones. Floating may not (Not completely ruled out) be an option as floating isn't very predictable on phones. Inline sometimes works sometimes not with browsers as I've seen.
This is sort of a large problem from a design standpoint and I'm hoping there's some kind of MVC method for creating a magical button that would work.
Clarification:
I think the best way to put this is I'm using some buttons as links. In the WebForms version, there were a few of the buttons that basically just redirected. So with that in mind:
Say I have three buttons but all three will need to post to different pages. This would suggest 3 different forms. Unfortunately that would also mean all three buttons would now appear as block elements. (Even though that's it's the form causing this.) Maybe I should be asking if in MVC there is a way to post back to the same controller to redirect from there? Redirect I've done, so that's not a big deal. Posting to a controller and evalutating a button based on it's value I haven't, but that almost seems like trying to recreated WebForms functionality of postback.
Example http://www.eythere.com/images/eythere.jpg
From that image, the top three buttons are merely postbacks to redirets.
UPDATE:
Have attempted tables and floating divs. Tables don't work well with small phones like Razors since they tend to ignore TDs and just make on big vertical column.
Tried floating divs like thus:
<div >
<form >
<input type="submit" style="float:left;"/>
</form>
<form>
<input type="submit" style="float:left;"/>
</form>
<form>
<input type="submit" style="float:left;"/>
</form>
</div>
Problem is it shows the buttons in two rows (That's fine) but the two buttons in the same row aren't aligned vertically. The second one is off by a little bit. Almost to the point that it looks like a Final Four bracket.
May have to go with the multiple buttons to a form thing. This seems to contradict the MVC design but I don't see another way around this.
When you post a form, the name attribute of the button used to post it is sent as a form value. Give each button a name, and then check the Form collection (or an Asp.Net MVC intermediary) for the button's name.
if(!String.IsNullOrEmpty(Request.Form["myButtonName"])) {
//myButtonName has been pressed.
}
EDIT:
Problem is that turns out a form is a block element so that it's not possible to get to button next to each other. (Why they are block elements I'd like to know.)
Forms are block elements because if they were inline elements it would be invalid to nest tags like p and div inside of them (both of which are handy in constructing forms).
If I understand what you are asking, then sorry there is no such function. You would have to find or create your own method that would identify the client and then output the correct HTML code and CSS to accommodate that device. It may be better to find a solution on the user side of the code. You could maybe use display:inline; to forge the button to act like an inline element no matter what. It should work in all major browsers (http://www.quirksmode.org/css/display.html), and this this probably includes the iPhone browser because it is safari based.
It would probably help if you could explain a bit more about how you want the stuff to interact. That said, no law says a form can only have one submit button, and, when submitted it is possible to figure out which button is clicked--the name/value (text) of the button appear in the posted data. Exactly how to handle that really goes to what needs to happen and how you want to architect it, but you can definitely give a form multiple buttons.
--UPDATE--
Thanks for the clairifications. I think your best bet would be to use normal links and style them a bit:
a.button { display: block; width: 100px; float: left; }
They should be nice big clickable things in iTouches and in other more modern mobiles and degrade nicely in older mobile stuff as there really ain't nothing that can do HTML that doesn't support links.
this might solve your problem
another solution: if you can use javascript, make a DIV and a onclick action on it
like what Jeff did here on SO with the [Votes] | [Answers] | [Views] "button" on the home page on the left side of every question
Use css to style anchor links like buttons. That way you get rid of the useless forms and maintain affordability and clickability.
I haven't tried this so I can't say if it will work or not, but could you not just set the forms on the page to "display:inline"?
If you are not collecting data from the user, than they just look like simple links.
HTML buttons don't have to be inside forms. You can have a button with a javascript onclick handler that does whatever you want, like setting a form's action and submit it, or load a new document.
<input type="button" value="Home"
onclick="location.href='/index.php'" />
<input type="button" value="Rooms"
onclick="var f=document.getElementById('myform');f.submit()" />
<input type="button" value="Create"
onclick="var f=document.getElementById('myform');f.action='/create.php';f.submit()" />
Those buttons can then be styled in any way.
If your form isn't collecting data, then all your buttons can behave like the "Home" button in my example.