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?
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 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
I read from this site [Site]: http://msdn.microsoft.com/en-us/library/windows/apps/hh968006.aspx
that aria-multiline is to provide the multi line attribute.
But when i applied to textbox, it doesn't seem to work. Can anyone please tell why. I have one more question, can anyone please tell me the difference between these two elements
<textarea rows="4" cols="50" id="text"></textarea>
<textarea rows="4" cols="50" aria-labelledby="aria-text-label" id="aria-text" role="textbox" aria-multiline="true"></textarea>
Thanks
ARIA attributes are declarative (informative). They inform browsers and especially assistive software what functional properties elements have, mainly due to JavaScript code that processes them, instead of making elements have functional properties. For example, if you used JavaScript to make a div element a multi-line input area, it would be appropriate to set aria-multiline="true" on that element. See the W3C WAI Primer.
Thus, the attribute is redundant for textarea (browsers can be expected to know what that element is). For input type="text" it could be used, but only if you have somehow managed to turn it to a multiline control.
The differences between the two elements presented in the question are:
They assign different id attribute values.
The latter declares a role attribute, which matches the default semantics and is not recommended in Using WAI-ARIA in HTML. (It is allowed, but it may confuse people who read the HTML source and mislead them into thinking that it has some effect.)
It also redundantly declares the element as multiline.
It additionally specifies that the element has a label, which is an element with id="aria-text-label". This is not redundant, but it is normally better, more accessible, to have the label declared in normal HTML markup, using the label element.
Have you read Remarks part of your link? Since textarea is multiline by default, so setting aria-multiline="true" will have no efect. This attribute sets what ENTER key do. In textarea and when aria-multiline="true" it will continue input to second row. But if you set aria-multiline="false" for textarea, it will act as <input type="text"/> - it will submit form on Enter key press and will not jump to second row.