WCAG - Screen Reader NVDA reading placeholder information - html

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.

Related

Html accessibility - read another element's description

Hello any accessibility gurus,
I want to have this button element, when tabbed on, would trigger the screen read of an input element instead.
I tried pointing the aria-labelledby from the button to the input, to have the input's aria-label being read out. But the button still reads out its own description, when tabbed on.
<fieldset>
<input type="radio" id="inputid" aria-label="read me">
<button aria-labelledby="inputid">don't read me</button>
</fieldset>
Is there a way to read another element's content?
Thank you,
2022-12-06 Edit:
Following Andy's comment, the input element is only visually hidden, so it was moved offscreen with css left: -10000px.
I believe aria-labelledby is not used according to the standards, which might explain undefined behaviour.
The Accessible Name and Description, step C mentions the following:
If the embedded control has role textbox, return its value.
That means that if an <input>, which has implicit role textbox, is used as part of an accessible name, not its label, but its value is used as the name.
Further, the ARIA standard on aria-labelledby reads:
If the interface is such that it is not possible to have a visible label on the screen, authors SHOULD use aria-label […]
The main purpose of aria-labelleby is to refer to part of the visible contents of an element like a <form> to label it. Most commonly, this would be a heading like <h2>.
The use case of this question is currently unclear to me. The example provided does not make sense with a single radio input.
If the <input> is completely hidden, visually and from assistive technology, why is it there in the first place? <input type="hidden"> would be the more correct input to use if the form data is needed
If it’s only hidden visually, both the button and the input can be focussed, which is terribly confusing. Does the input appear on screen once it receives focus?

what is the difference between placeholder and aria-placeholder in html5?

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

Accessibility: input with image - use value-, alt- or title-attribute?

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

Is using "placeholder" as an in-field label semantically wrong?

In-field labels are extremely popular now. They save space and look cool. There are many, many ways to accomplish them. It is now very easy to do using the HTML5 placeholder parameter for form inputs. You can even then create backwards compatibility with a bit of jquery if you want to.
But, is it semantically correct to use placeholder="Name" instead of <label>Name</label> or should a label element always be included and placeholder reserved to guide the user like this:
<label for="name">Name</label><input id="name" type="text" placeholder="Jane Doe">
If it's generally considered ok to use placeholder as either a label or an example, then that's definitely the easiest way to accomplish this effect. No javascript needed for modern browsers, no chance of submitting the label as the input value, etc. What are the semantic and practical drawbacks of doing this, if any?
The HTML5 specification explicitly calls this out. It says:
The placeholder attribute should not be used as a replacement for a
label. For a longer hint or other advisory text, place the text next
to the control.
Use of the placeholder attribute as a replacement for a label can
reduce the accessibility and usability of the control for a range of
users including older users and users with cognitive, mobility, fine
motor skill or vision impairments. While the hint given by the
control's label is shown at all times, the short hint given in the
placeholder attribute is only shown before the user enters a value.
Furthermore, placeholder text may be mistaken for a pre-filled value,
and as commonly implemented the default color of the placeholder text
provides insufficient contrast and the lack of a separate visible
label reduces the size of the hit region available for setting focus
on the control.
HTML5 spec notwithstanding, It's becoming popular to use the "Float Label Pattern". The label starts as a placeholder, but then moves up above the field once text has been entered.
There's a handy tutorial for it here....
http://webdesign.tutsplus.com/tutorials/ux-tutorials/implementing-the-float-label-form-pattern/

HTML img tag: title attribute vs. alt attribute?

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);
}