I have the following input on a site I'm currently reviewing:
<input type="submit" name="executeSearch" value="" alt="Execute search" title="Execute search" class="iconButton searchBtn">
Through the class attribut the input button is replaced by an search icon.
According to accessibility is this the right way? Or should the value attribute be used? The screenreader I tested this element with (NVDA) was able to read the text ("Execute search button").
An empty value and an icon added via CSS to convey the only important information is a failure according to WCAG 2.0: F3 - Failure (…) due to using CSS to include images that convey important information
Simplest solution: use an input[type="image"], keep that alt="Execute search" ("Search" would be more concise IMHO), add an src="/path/to/img" of course and remove both title and value attributes. Image can be an SVG and can be encoded in base64 (ideal when it's light for performance reasons: that's 1 resource not to be downloaded).
That [type="image"] seems outdated because it was widely used circa IE6, way before RWD but it isn't (proof of concept with an 8x16 viewBox and width*height SVG: it scales®)
Otherwise you can use a button element with type="submit". This element can contain SVG, HTML images, text hidden to screen readers (better known as .visually-hidden, .sr-only or .element-invisible in Bootstrap, WordPress, Drupal, etc). That's what I use when a "submit" has both text and image or icon because no :pseudo with input and text-only through #value
Some notes on your current markup:
#alt should only be used with input[type="image"]
#value shouldn't be used with type image and otherwise should never be empty
#title should only be there (on links and "buttons") if it adds something to the existing information (like Subscribe ⇒ Subscribe to the newsletter or Edit ⇒ Edit something in particular)
According to accessibility is this the right way? Or should the value attribute be used?
An input[type='submit'] button does not accept an alt attribute
Some screenreaders may use the title attribute, but it's still useful for non screenreader users
Using the value attribute is the recommended approach for screenreader users
Related
please , I need to know difference between area-placeholder and placeholder ? when area-placeholder will appear in input field
<input type="search" placeholder="Search" aria-placeholder="Search2" />
edit (added a deeper explanation)
ARIA labels are used to express semantics that HTML can't express on its own, i.e bridging areas with accessibility issues that can't be managed with native HTML. It works by allowing you to specify attributes that modify the way an element is translated into the accessibility tree.
for example, let's use a list item as a custom checkbox (the CSS class 'checkbox' gives the element the required visual characteristics.
<li tabindex="0" class="checkbox" checked>
Receive promotional offers
</li>
for sighted users, this will work fine, but a screen reader won't give an indication that this element is a checkbox, so users with low vision might miss this element.
using ARIA will give the element the missing information for the screen reader to properly interpret it.
there are many ARIA attributes, and if you plan on using them (you should!) i recommended reading more here
Aria-label allows us to specify a string to be used as the accessible label. This overrides any other native labeling mechanism, such as a label element — for example, if a button has both text content and an aria-label, only the aria-label value will be used.
A placeholder is a text that appears in the form control when it has no value set. The HTML placeholder attribute enables providing a sample value or a brief description of the expected format for several HTML types and .
If you are creating a textbox using any other element, the placeholder is not supported. That is where aria-placeholder comes into play. The aria-placeholder attribute can be used to define a short hint to help the user understand what type of data is expected when a non-semantic form control has no value.
<p id="date-of-birth">Birthday</span>
<div contenteditable role="textbox" aria-labelledby="date-of-birth"
aria-placeholder="MM-DD-YYYY">MM-DD-YYYY</div>
The placeholder hint should be shown to the user whenever the control's value is empty, including when a value is deleted.
The aria-placeholder is used , in addition, to, not instead of, a label. They have different purposes and different functionality. A label explains what kind of information is expected. Placeholder text provides a hint about the expected value.
ARIA is only modifying the accessibility tree for an element and therefore how assistive technology presents the content to your users. ARIA doesn't change anything about the function or behavior of an element. When not using semantic HTML elements for their intended purpose and default functionality, you must use JavaScript to manage behavior.
for a more detailed explanation, you can visit the aria-label page on Mozilla
I came across a problem working with a screen reader (NVDA) reading placeholder information when it was not supposed to.
I have input with a title and placeholder. The screen reads placeholder first and then reads the title:
<div>
<input type='text' placeholder='DD.MM.RRRR' title='Insert date correctely in the format DD.MM.RRRR' />
</div>
Based on the information provided by the web, the NVDA shouldn't read placeholder at first place, it should only be available for visual purposes. I've already tried some workarounds using aria-describedby and aria-placeholder.
The basic question is how to make placeholder invisible for screen readers?
JSFiddle
Adding on to what #GrahamRitchie said, keep in mind that all interactive elements have an "accessible name" and an "accessible description". Both are typically announced by a screen reader although you can change your screen reader settings to turn off the description (sometimes referred to as a "hint" in the screen reader settings).
How the accessible name and description are computed can be very handy in understanding this situation. There is a precedence list of attributes that are inspected to compute the name and description. Once an attribute is found, the remaining items in the precedence list are ignored. It's basically this:
aria-labelledby
aria-label
placeholder attribute or <label> element
other stuff
title attribute
So if you have both an aria-labelledby attribute and a <label> element, only the aria-labelledby attribute will be used because it has higher precedence. The label will be ignored.
That being said, since your original code had an <input> that didn't have a label, the accessible name used the placeholder attribute. If you change your code to have a <label>, then the label will have higher precedence than the placeholder and the placeholder will be ignored for the accessible name. However, the placeholder might be considered for the accessible description.
You can see this in the accessibility inspector in Chrome. In the panel where CSS is usually displayed, there is an "Accessibility" tab (usually hidden in the ">>" menu).
Displaying the accessibility properties helps understand what is being announced by the screen reader.
Notice the "Name" (which is the accessible name) is "DD.MM.RRRR" and it says it comes from the placeholder attribute. It also says the "Description" (which is the accessible description) is "Insert date correctly...", which comes from the title attribute (but the tool doesn't tell you which attribute contributed to the accessible description).
If you were to have a <label> for your <input>
<label for="foo">date</label>
<input id="foo" type='text' placeholder='DD.MM.RRRR' title='Insert date correctely in the format DD.MM.RRRR' />
Notice how the accessible name changes. The placeholder is no longer used. The description stayed the same.
Now, all that being said, there are still two confusing points. The accessible name calculation, in step D, says if there's an attribute or an element that provides alternative text, then use it. But the example they give of an attribute is title. But down in step I (eye), it says if there's a tooltip attribute, then use it. Well, the title attribute IS the tooltip attribute so why is it used as an example in step D if it's going to be used in step I? I don't know, sorry. It's an ambiguity in the spec.
And just to add to the confusion, even though Chrome shows the accessible description is the title attribute, the placeholder is STILL read after the description, as if it were part of the description, even though it's not shown as part of the description in the inspector. I would consider that a bug. Whether it's a Chrome bug or NVDA bug remains to be determined.
Screen readers will read the placeholder attribute when the field is empty.
This is expected behaviour in screen readers that support placeholders.
I think the confusion comes where it is advised not to use a placeholder instead of a label.
The reason is that once the field is filled in a lot of screen readers will not read the placeholder (as it is no longer shown) and so a completed field no longer has a name that can be read out by the screen reader. (plus visible labels help people with cognitive disabilities etc.)
So assuming that in production you have a <label> that is visible and is properly associated with your <input> then there is nothing you need to do here.
Are there any differences between these two screen reader techniques on forms, and is one more encouraged than the other:
<label for="titleInput">Title</label>
<input type="text" id="titleInput" name="title" value="">
<div>Title</div>
<input type="text" aria-label="Title" name="title" value="">
The first way has always been the way to set this up, but since WAI-ARIA was introduced, it's got me thinking if using aria-label with forms is the better than using <label for="x">.
As a rule of thumb: If a real element can do the job, then use a real element. ARIA is what you fallback to when there is no real element that expresses the semantics or when you are doing something really weird which prevents you using the normal element.
(Most of the time, when you are doing something really weird, you should stop doing the weird thing instead).
In this particular case, there are a couple of major differences between the two.
Browsers won't extend the click target to the div element as they would with a label element. Clicking the label will focus the input, clicking the div will not.
You now have two labels. The div and the attribute provide the same information in two different places. The attribute doesn't replace the div, so a screen reader will read out the div text and the label associated with the input.
Use a <label>. It is specifically for associating text with a form control.
aria-label is designed for providing a text description of some content which a screen reader can't read out. e.g. when you are using a background image to convey information instead of using an <img> with an alt attribute (See my previous note about weirdness).
Aria-label is for accessibility. If Aria-label is added, on voice-over i.e (cmd +F5 on MAC or JAWS on windows machine will read whatever is typed inside the aria-label attribute of the HTML tag. This functionality is highly helpful for visually disabled users. Read here https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute
Label is HTML tag , just like <form> or <h1>..<h6> , etc tags, when tag is used it renders Label on the UI. E.g: <Label>ENTER NAME</Label>
I wanna ask about the alt attribute in an input tag.
As I found on many sites, the alt attribute is used when we have an input with type image.
1/ Can it be used for an input type button?
<input type="button" alt="myAction.myMethod" />
2/ what is its meaning?
The attribute that defines the mouse hover tooltip text is title, not alt, as asked and answered in Tooltips for Button elements.
The title attribute documentation page at https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/title (MDN) also has a few notes about accessibility issues for the tooltip effect on mouse over and suggests some alternative techniques.
No
It doesn't have one
The only kind of input that can have an alt attribute is type="image" where it provides a text alternative for when the image can't be rendered (e.g. because it failed to load, because the browser doesn't support images, or because the user is employing screen reader software (usually to compensate for a vision related disability)).
See http://www.w3schools.com/tags/att_input_alt.asp
I quote
The alt attribute provides an alternate text for the user, if he/she
for some reason cannot view the image (because of slow connection, an
error in the src attribute, or if the user uses a screen reader).
Note: The alt attribute can only be used with <input type="image">.
So, no. And since it cannot be used with a button, it has no meaning.
For a button class I found it was title="Copy to clipboard" that worked for me.
I was browsing Amazon and I noticed that when searching "1TB" if you hover the mouse cursor over the stars rating image, you only see the score if using IE. If you are using another browser then the score won't show.
A rating of 3.8 and a rating of 4.2 both show up as 4 stars. Of course a 3.8 stars vs 4.2 stars (76% vs 84% score) could make a difference!
This is because the standard way of displaying alt text is only when the user turns off graphics or when the browser is "read out" (e.g browser for users who are visually impaired). IE however, shows it on hover.
So I think if Amazon is to show it regardless of the user's browser, then title should be used in addition to alt. Would you agree?
They are used for different things. The alt attribute is used instead of the image. If the image can't be shown, and in screen readers.
The title attribute is shown along with the image, typically as a hover tooltip.
One should not be used "instead" of the other. Each should be used properly, to do the things they were designed to do.
I'd go for both. Title will show a nice tooltip in all browsers and alt will give a description when browsing in a browser with no images.
That said, I'd love to see some stats of how many "surfers" out there going to a "store" to browse merchandise actually have images turned off or are using a browser that doesn't support images. I think the days where 90% of the population is using a 28k modem to connect to the InterWeb is looooong over.
alt and title are for different things, as already mentioned. While the title attribute will provide a tooltip, alt is also an important attribute, since it specifies text to be displayed if the image can't be displayed. (And in some browsers, such as firefox, you'll also see this text while the image loads)
Another point that I feel should be made is that the alt attribute is required to validate as an XHTML document, whereas the title attribute is just an "extra option," as it were.
That's because they serve different purposes and they both should be used not just one over the other.
The "alt" is for what you guys already said, so you can see what's the image it's all about if the image can't be displayed (for whatever reason), it also allows visually impaired people to understand what's the image about.
The "title" attribute is the correct one to show the tooltip with a title for the image.
In my opinion should the alt text always describe what is visible in the picture, for the case that the image is not displayed.
alt = text [CS]
For user agents that cannot display images, forms, or applets, this attribute specifies alternate text. The language of the alternate text is specified by the lang attribute.
w3.org
I believe alt is required for strict XHTML compliance.
As others have noted, title is for tooltips (nice to have), alt is for accessibility. Nothing wrong with using both of them, but alt should always be there.
ALT Attribute
The alt attribute is defined in a set of tags (namely, img, area and optionally for input and applet) to allow you to provide a text equivalent for the object.
A text equivalent brings the following benefits to your web site and its visitors in the following common situations:
nowadays, Web browsers are available in a very wide variety of platforms with very different capacities; some cannot display images at all or only a restricted set of type of images; some can be configured to not load images. If your code has the alt attribute set in its images, most of these browsers will display the description you gave instead of the images
some of your visitors cannot see images, be they blind, color-blind, low-sighted; the alt attribute is of great help for those people that can rely on it to have a good idea of what's on your page
search engine bots belong to the two above categories: if you want your website to be indexed as well as it deserves, use the alt attribute to make sure that they won't miss important sections of your pages.
Title Attribute
The objective of this technique is to provide context sensitive help for users as they enter data in forms by providing the help information in a title attribute. The help may include format information or examples of input.
Example 1: A pulldown menu that limits the scope of a search
A search form uses a pulldown menu to limit the scope of the search. The pulldown menu is immediately adjacent to the text field used to enter the search term. The relationship between the search field and the pulldown menu is clear to users who can see the visual design, which does not have room for a visible label. The title attribute is used to identify the select menu. The title attribute can be spoken by screen readers or displayed as a tool tip for people using screen magnifiers.
<label for="searchTerm">Search for:</label>
<input id="searchTerm" type="text" size="30" value="" name="searchTerm">
<select title="Search in" id="scope">
...
</select>
Example 2: Input fields for a phone number
A Web page contains controls for entering a phone number in the United States, with three fields for area code, exchange, and last four digits.
<fieldset>
<legend>Phone number</legend>
<input id="areaCode" name="areaCode" title="Area Code" type="text" size="3" value="" >
<input id="exchange" name="exchange" title="First three digits of phone number" type="text" size="3" value="" >
<input id="lastDigits" name="lastDigits" title="Last four digits of phone number" type="text" size="4" value="" >
</fieldset>
Example 3: A Search Function
A Web page contains a text field where the user can enter search terms and a button labeled "Search" for performing the search. The title attribute is used to identify the form control and the button is positioned right after the text field so that it is clear to the user that the text field is where the search term should be entered.
<input type="text" title="Type search term here"/> <input type="submit" value="Search"/>
Example 4: A data table of form controls
A data table of form controls needs to associate each control with the column and row headers for that cell. Without a title (or off-screen LABEL) it is difficult for non-visual users to pause and interrogate for corresponding row/column header values using their assistive technology while tabbing through the form.
For example, a survey form has four column headers in first row: Question, Agree, Undecided, Disagree. Each following row contains a question and a radio button in each cell corresponding to answer choice in the three columns. The title attribute for every radio button is a concatenation of the answer choice (column header) and the text of the question (row header) with a hyphen or colon as a separator.
Img Element
Allowed attributes mentioned at MDN.
alt
crossorigin
decoding
height
importance (experimental api)
intrinsicsize (experimental api)
ismap
referrerpolicy (experimental api)
src
srcset
width
usemap
As you can see title attribute is not allowed inside img element. I would use alt attribute and if requires I would use CSS (Example: pseudo class :hover) instead of title attribute.
You should not use title attribute for the img element. The reasoning behind this is quite simple:
Presumably caption information is important information that should be available to all users by default. If so present this content as text next to the image.
Source: http://blog.paciellogroup.com/2010/11/using-the-html-title-attribute/
HTML 5.1 includes general advice on use of the title attribute:
Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to apear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).
Source: http://www.w3.org/html/wg/drafts/html/master/dom.html#the-title-attribute
When it comes to accessibility and different screen readers:
Jaws 10-11: turned off by default
Window-Eyes 7.02: turned on by default
NVDA: not supported (no support options)
VoiceOver: not supported (no support options)
Hence, as Denis Boudreau adequately put it: clearly not a recommended practice.
I would ALWAYS go with both the alt and the title attributes. They are each used for different purposes: alt for image replacement on missing images, slow image downloads, or in assistive technology, while title is for rollover interactivity and additive image description.
In addition, in HTML5 you should start using the new HTML5 picture element wrapped in figure with full WPA-ARIA attributes for greater accessibility, as well as support of assistive technologies, screen readers, and the like. Because this element is not supported in many older browsers...BUT degrades gracefully...I recommend the following HTML design pattern now for images in HTML:
<figure aria-labelledby="picturecaption2">
<picture id="picture2">
<source srcset="image.webp" type="image/webp" media="(min-width: 800px)" />
<source srcset="image.gif" type="image/gif" />
<img id="image2" style="height:auto;max-width: 100%;" src="image.jpg" width="255" height="200" alt="image:The World Wide Web" title="The World Wide Web" loading="lazy" no-referrer="no-referrer" onerror="this.onerror=null;" />
</picture>
<figcaption id="picturecaption2"><small>"My Cool Picture" [A License] , via Wikimedia Commons</small></figcaption>
</figure>
The code above has many extra "goodies" beside alt and title, including ARIA attributes, support for WebP, a media query supporting higher resolution imagery, and a nice fallback pattern supporting older image formats. It shows a fully decorated image example that uses new technologies while still supporting old ones with progressive design patterns.
Many developers have been using this pattern now for over 20 years to deal with IE and other issues. So this is not new knowledge. Its just been rediscovered by new developers that didn't bother to learn from the past.
REMEMBER...ALWAYS SUPPORT THE OLD BROWSERS!
alt attribute is for visually impaired users that would use a screen reader. If alt is missing from ANY image tag, the entire url for the image will be read. If the images are for part of the design of the site, they should still have the alt but they can be left empty so the url does not have to be read for every part of the site.
No, alt is better because its purpose is to provide an "alternate" text in the event that the image cannot be view (whether it be that the image is missing or that the browser itself is incapable of displaying it).
The MVCFutures for ASP.NET MVC decided to do both. In fact if you provide 'alt' it will automatically create a 'title' with the same value for you.
I don't have the source code to hand but a quick google search turned up a test case for it!
[TestMethod]
public void ImageWithAltValueInObjectDictionaryRendersImageWithAltAndTitleTag() {
HtmlHelper html = TestHelper.GetHtmlHelper(new ViewDataDictionary());
string imageResult = html.Image("/system/web/mvc.jpg", new { alt = "this is an alt value" });
Assert.AreEqual("<img alt=\"this is an alt value\" src=\"/system/web/mvc.jpg\" title=\"this is an alt value\" />", imageResult);
}