I noticed on a few places (mainly Youtube's comments), there are "textbox" instead of the normal "textarea".
<div role="textbox" aria-multiline="true"></div> vs <textarea></textarea>
Also I see <div role="textbox"></div> instead of <input type="text">
Is there any functionality advantages to use role="textbox" instead of textarea or input? Or is this just pure preference? For example, is it easier to modify or edit using Javascript?
As you see above, I am selecting the comment box with Chrome's inspector.
Now I added text to the comment box, and the text appears inside the div element stated above when viewing Chrome's inspector.
I'm not sure where you are seeing that a div should be a textbox, but that's incorrect. The tag is input, not div.
But, to your larger question the role attribute pertains to the WAI-ARIA standard, which relates to user accessibility for those who use assistive technologies, such as screen readers. It allows those users to navigate a page more easily because the screen reader has a better idea of what elements are what on the page.
There are no new functions that the text field takes on because of the use of this attribute. ARIA is about accessibility.
You can read a bit more about this, particularly relating to text fields at: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_textbox_role
Related
I am trying to optimize a few components for screen readers, however Android Talkback proves to be a challenge....
Here is a very simplified example for the code:
<div class="wrapper">
<form>
<span role="presentation" aria-hidden="true">
This should not be read by Talkback
</span>
<input aria-label="This should be read by Talkback" />
</form>
</div>
The text inside the span is updated dynamically, and is positioned absolutely over the input - just to appear like an animated placeholder, without actually being read by screen readers. That is what the aria-label is for. However, TalkBack still seems to recognize the span - so it reads the content of the aria-label first, then continues reading the text in the span... role "presentation" or role "none" did not prevent this, neither did moving the text even further from the input. (For example, outside the form). Is there any way to prevent this?
The role attribute only changes the type of element that Talkback and other screen readers announce. Setting it to presentation or none just removes the semantic type of element. A <span> does not have a native role by default so it's essentially presentation/none implicitly and won't have any effect.
aria-hidden is the key. It will hide the element from the screen reader. (CSS display:none and visibility:hidden will also hide an element from the screen reader but it also makes the element invisible to sighted users too.)
Your code example should work just fine with Talkback. However, you mentioned that you dynamically change the contents of the <span>. That's not a problem but is there a chance that when you updated the text, the aria-hidden got removed?
I have used aria-hidden on Android without any trouble.
The solution in my example was already enough to fix the issue.
aria-hidden prevents the span being focusable, and if the span is located before (and not after), TalkBack will not interpret the text as being part of the input.
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".
My product has an area where we want to display a default value (let's say the name of a document page), but when the user focuses on it and hits the space bar, it becomes an editable field. We are trying to write accessible code, and I was wondering if anyone had guidance about how to indicate to someone using a screen reader that this content is editable?
The way we are currently handling it in the code is to have a div with the name and when the user clicks (or focuses and hits space bar), it turns into an input. (They can hit enter or a button to save.) Are there ARIA values we could leverage for this or some other native solution?
Default:
<div>Page title <button>Click to edit page title</button></div>
When editing:
<input maxlength="500" value="Page title" />
We don't have a button to save right now. You hit enter or remove focus from the input, and it automatically updates.
The ARIA in HTML document defines "Element with contenteditable attribute" as having an implicit aria-readonly="false" attribute. This property is only available for some ARIA roles according to ARIA documentation and the textbox role is the more appropriate in your case. In this case no button is needed.
If your editable section does not contain HTML code (like links), it seems useless to use a contenteditable section and you should use instead standard input or textarea elements with appropriate CSS design, respectful of WCAG standards (i.e. Editable fields have to be distinguishable from text)
If your editable section does contain HTML code, then you would have to use a contenteditable atttribute. You have to identify the section as being a role=textbox element and it must be focusable with tabindex=0 attribute. This can be done on page load (without button), or after clicking a button outside the section (if you need, for instance, to be able to activate the inner links in normal reading context).
I am looking to disable a few html controls and I am running into cross browser issues with the differences between IE and Firefox/Webkit browsers. The primary issue is evident with the following line:
<input type="text" name="badIE" disabled="disabled" style="color:blue;" value="IE won't show this correctly" />
In IE, the above input would have grey text, while the text is blue in every other browser I have tested. It would appear that IE allows the disabled field of a text input to take precedence over the CSS rules for the text color. Is there any established best practice or IE CSS hack to address this type of issue?
According to the upvoted (but not accepted) answer here, you're kind of stuck with using 'readonly'.
Just out of curiousity - why are you displaying text in a textarea that you don't even want your users to be able to focus on? Seems to me you'd be better off displaying that in a regular text HTML element (e.g. <p>).
It turns out that there are few different ways to attack this problem but there isn't one exact answer. In order to provide the most complete answer possible, here is a list of the possible solutions.
Accept the differences between browsers and continue using the disabled field. This is probably the right answer. As chipcullen suggested on his comment, there is rarely a necessity that all browsers look identical. It is better to simply accept the differences between and work with them.
Use the readonly attribute instead of disabled. The problem with this method is that a user can still interact with a readonly control. For example, users could focus on the control or stick a blinking cursor in the middle of the text. If interaction is a major concern, you can always shield the disabled control behind an invisible element, although that method is on the hacky side.
The option I chose was to replace the input elements with a pure text element. Although this method might not be as straightforward as it might sound. My page was interactive and certain elements would be enabled/disabled depending on client side actions. In order to handle the transition, I threw together the following Javascript (after chipcullen's suggestion and with the help of jQuery):
function disabledToSpan() {
$('input[type=text]:disabled, textarea:disabled').replaceWith(function () {
return $('<span>' + $(this).val() + '</span>').attr('class',
$(this).attr('class')).addClass('disabledTextInput');
});
}
In summary, this will find all disabled text inputs and textareas, switch them to spans while preserving both their values and classes, before finally adding a disabledTextInput class to specially stylize the disabled elements.
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.