What would be the best way to markup a menu button? The idea is to have a button with a text like "add" to fold out and show the options you can add.
I like the <menu> html5 tag but the label attribute doesn't sit well with me as it would mean the text would only show if a piece of JS has been loaded that actually places the text (ok I could use css generated content, but that doesn't work in IE7/8).
I thought about a <dl><dt>add</dt><dd>...</dd></dl> construction but I don't think it covers the wanted semantics.
Do you have any ideas?
You can place the actual element inside the label and still maintain a proper relationship between the two.
For example:
<label for="elementName"><element name="elementName" attribute="" attribute="">Element Label</element></label>
Similar to how one would markup radio buttons. I would attempt this sort of approach first, however, a simple unordered list might actually be what you are looking for, rather than a definition list, as with a definition list you need to specify a dt and a dd for each item.
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".
Is there any alternative to <div>? My website is losing "accessibility" because I cannot set focus on a <div>. What control should I use in order to replicate <div> and still hold focus?
This is what my HTML looks like:
<div style="height:70px; overflow:hidden" id="divMsg">
<div class="DivClass">abcdefg abcdkfjghfjdfkj</div><br>
<div class="DivClass">abcdefg abcdkfjghfjdfkj</div><br>
</div>
You can add tabindex to make it focusable; however, this is usually not enough. If you want the element to be clickable, you will also need to add a keydown or keypress handler so that the user can activate it using ENTER, similar to a A link. Otherwise the user will be able to tab to it, but may not be able to do anything with the link after.
If you are trying to create a clickable element, it is sometimes simpler to start with a A tag, and then style it so that doesn't look like a link. A elements respond to both keyboard and mouse and fire onclick for both, so you don't have to do additional keyboard input handing like you do with a DIV.
Finally, if you are making a DIV or A that visually looks like a button or some other control, add the appropriate ARIA role so that a screenreader will call out the appropriate element type - eg.
Complete Transaction
Just give it a tabindex attribute.
If you are specifically looking for accessibility, try out the new HTML 5 tags like <article>. So for example a textreader knows what to read, and your page is much better structured.
Check out this site.
To answer your exact question, it depends why you are using the div; I'm guessing for layout. The tab ordering is dependent upon more than tabindex, as defaults and overflow affects positioning and focus.
To be more specific, you won't use a div to latch onto for tabindex. Rely upon JavaScript and a unique ID; <div class="content" id="page1">
This will also provide you an anchor so you could use http://index.html#divMsg to link focus to the exact place in your HTML document. Note you have only one div ID and reuse the same div class twice in your example.
If this is all new to you the article on difference between ID and CLASS may be of interest to you
Links (element a) and form elements (input text and alike, file, radio and checkbox, submit, image and type button, select, textarea, button element, etc) are focusable by default.
Thumb rule: if an element does something, it should be a link or a form element part of a form. (OT: I guess I've a problem with conjugation here but can't find exactly what - english isn't my mothertongue)
Think twice (at least :)) before using the tabindex attribute: it'll work for a while in your project and then you make some modification elsewhere and suddenly all is broken. And it'll break again, again and again.
For testing with Safari, you'll need to modify Preferences: this browser (maybe also Chrome?) only cycle by default through form elements and not links. Users of keyboard cycle through every focusable elements I guess, like in IE and Firefox.
To learn further, Web Content Accessibility Guidelines 2.0 (WCAG 2.0) have Sufficient Techniques (and "Failure(s)" also) about keyboard use.
So I've got a form, who's content will change based on a dropdown list of different reports. So the question is, how horrible would it be to include a select box as the legend tag for the fieldset?
I know that technically it works, and semantically it makes sense (the actual text of the legend tag, the selected value is a caption of the contents of the fieldset). But I can't help but feel dirty doing it.
If it's semantically correct and the page HMTL validates then I don't see why not.
However, I'm sure there are other UI solutions to your problem. Perhaps using jQuery UI's tabs or something similar. http://jqueryui.com/demos/tabs/
I'm working with an <input> field and I'd like to style part of the field as the user's typing in a different color. For example, let's say the <input> has a style declaration of color: red; and I want to change part of it to color: blue;. Is there any way this is possible?
If there isn't (as I suspect), any creative ideas on how I can simulate this effect while still preserving semantic mark-up?
Your suspicions are correct: styles will apply to the whole input only.
As styles can apply to the entirety of an element only, a solution will require at least one element per required colour.
Consider the division of the input field with respect to the point at which the user is making changes. There are three sections of the input:
that before the point at which changes are being applied
that after the point at which changes are being applied
that at the point the changes are being applied
You cannot achieve this with a single input element. And as the point at which the changes are being applied can change, the portions of the 'input' wrapped by the three elements will also change. JavaScript is required for a solution.
You should initially include a regular input element and forgo any of the required colouring. Use JavaScript to replace the input with a suitable container element. This can be styled to mimic an input element.
As changes occur, use JavaScript to identify the above-mentioned three divisions. Wrap them in suitable elements (spans would be ideal) and colour as needed.
Consider the following starting point for the generated replacement markup:
<div class="input">
<span class="nonEdited before">foo</span>
<span class="edited">fizz</span>
<span class="nonEdited after">bar</span>
</div>
Use click, keydown and keyup events to figure out the three divisions for the input and to apply wrap the three portions of the faked input as required.
As others have said, you can't do this with styles and static markup.
You could probably do it with a Flash-based form.
But, if I had to this, I'd use jQuery to overlay divs, with the colorized text, atop the <input>.
Algorithm:
Use a normal <input> with whatever default styles are desired. The contents of this input will never change except by user action.
jQuery monitors that <input>. When it detects trigger word(s), it adds a <div> after the input and fills it with the trigger word(s) -- styled as desired. Probably one <div> per word or phrase is best.
jQuery then positions the new <div>, absolutely, directly over the trigger word(s).
Getting the trigger word(s) offset within the <input> might not even be necessary, because the previous words could also be in the overlay <div> -- either styled defaultly or with visibility: hidden.
But, if only the trigger word(s) are desired in the overlay, then using a fixed-width font, like Courier, will help with the sub-positioning.
Take care that the overlay does not interfere with the user trying to mouse or key to certain parts of the <input>. IE, probably don't want to cover any more of the <input> than necessary, and set a click() handler to relay focus.
Alternate, user friendly and simpler approach:
Rather than try to do funky, non-user-expected things to the input, take a page from Jakob Nielsen and from sites like StackOverflow.
Just have a plain ol' <input>, but underneath it, show the formatted text as it comes in.
You can achieve this with (a lot of effort and) a div with the contentEditable attribute present. This is how most web-based WYSIWYG editors achieve rich formatting of inputs. See here for more info: http://ajaxian.com/archives/on-browser-wysiwyg
You can keep differently styled divs side by side in a container overlapped by a transparent input. Modify the widths of the styled divs on the basis of your input entry.
For example, to color input background for leading and trailing spaces:
<div class="bckg-container">
<div id="bckg-leading" class="bckg spaces">
</div>
<div id="bckg-middle" class="bckg">
</div>
<div id="bckg-trailing" class="bckg spaces">
</div>
<br style="clear: left;" />
</div>
<input id="inpt" type="text" placeholder="Add leading/trailing spaces" maxlength="20" />
The three divs inside the container will change their width with input change.
Check the working example in jsfiddle http://jsfiddle.net/TalhaAwan/ywyw4qq5/
You might be able to do it with some edit in place javascript (if it's not possible in pure html/css):
http://www.appelsiini.net/projects/jeditable/default.html
That jQuery plugin doesn't use html input fields so it could be possible to style different parts of the input. It has a couple of hooks for callbacks which you could use to style the input. Hope that helps as an idea.
You can have a label mocking that input and the real input to be hidden, then you can do a lot of things beteen label tags (e.g. colored spans).