similar thing happening here with this code. Browse mode focus not going to list items.
{<ul style="
margin: 0px;
padding: 0px;
"><li class="attachmentsContainerStyle-319" style="
text-align: unset;
" role="listitem" aria-setsize="2" aria-posinset="1">Screenshot 2023-01-09 at 4.34.36 PM_2023-01-12T17:10:00.6072590Z.png</li><li class="attachmentsContainerStyle-319" role="listitem" aria-setsize="2" aria-posinset="2"><p class="attachmentStyle-320"><i data-icon-name="TextDocument" aria-hidden="true" class="attachmentIconStyle-365"></i> Screenshot 2023-01-09 at 4.34.36 PM_2023-01-12T17:10:47.4149896Z.png</p><div><button type="button" class="ms-Link jaIaction-366" aria-disabled="false"><i data-icon-name="Download" aria-hidden="true" class="jaIactioIcon-367"></i>Download</button><button type="button" class="ms-Link jaIaction2-368" aria-disabled="false"><i data-icon-name="Delete" aria-hidden="true" class="jaIactioIcon-367"></i>Delete</button></div></li></ul>}
I want the screenreader to read list item 1 of 2 but the focus directly going to the document name in the list item that is in <p> container.
Your original question is about NVDA and browse mode but you tagged the question with android-a11y. I'm going to ignore android for now.
With NVDA in browse mode, did you try navigating to your list using the L key or to each list item using the i key?
If your main concern is hearing "X of Y" as you navigate each list item, that's totally up to the screen reader itself in addition to user settings. A user can change their verbosity settings and totally turn off the announcement for a list start/end as well as the position within the list, so there's no way you can force that announcement other than having literal "X of Y" text in your code (visibly hidden) for the screen reader to announce.
I noticed you had aria-postinset and aria-setsize in your sample code. I'm assuming you were trying to force the "X of Y" announcement. Those attributes are not needed when you're using semantic <ul> or <ol> elements and, as you probably noticed with your testing, does not force the "X of Y" announcement. That again is up to the screen reader software and the user settings.
Same with role="listitem" - it's not needed in your example.
Related
<span tabIndex='0' aria-label={ariaLabelText} className={classesContainer}>
<span className={classesItem}>{cartItemCount}</span>
</span>
I am trying to read the cart item count
As you will discover from this excellent resource aria-label is not supported on <span> because WAI-ARIA specifies <span> as a 'generic' role, which in turn means that it cannot be named.
You can (of course) override the default role by adding a role attribute which supports naming. Choose wisely. If this is going to be keyboard focusable (which your tabindex value suggests) then you should choose an operable role, such as button or link. Better still, use the HTML5 equivalent : <button> or <a> respectively.
In this particular case, where you simply want to announce the number of items in a cart, I would assume that the 'cart' itself is some kind of button, or perhaps a hyperlink, and the number of items in the cart is a kind of description or annotation for that element.
Your 'cartItemCount' can be included as part of the name, or not as you prefer. In the example below, it is excluded from the name by aria-hidden.
Alternatively, an annotation such as this might call for aria-describedby, so you might do something like this:
<button class="cart" aria-describedby="cartItemCount">
<span class="visibleLabel">{ShoppingCartText}</span>
<span aria-hidden="true" id="cartItemCount" class="items">{cartItemCount}</span>
</button>
In this example, 'cartItemCount' span is excluded from the button's accessible name (using aria-hidden) yet still exposed to assistive technology via aria-describedby.
As a design consideration, the 'description' of aria-describedby is something which assistive tech users might prefer to disable, relying wholly on naming (at least sometimes), so your annotation might not be 'announced' if it is not part of the name.
Screen readers and other ATs will offer different ways of accessing or muting this 'description' value when an element is in focus.
Note: The ARIA annotations spec, not quite final at time of writing is slated for inclusion in WAI-ARIA 1.3. It offers the aria-description attribute (already supported on some browsers) which will allow such state annotations to be added without creating additional elements.
The VoiceOver screen reader on Mac is able to read each element in the page by using Control-Option + left/right/up/down.
Since you are using aria-label then you are simply overwriting any text which would be presented inside the span. So, your span would need to use `aria-label="{ariaLabelText} {cartItemCount}"
However, why not simply add everything as a bit of text inside the span and be done with it?
I suspect you want to display a number, be able to tab to that cart number and when you reach there via VoiceOver you want to be able to reflect some extra bit of text to the screen reader users.
For that you need to do something different:
<button>
<span class="visually-hidden">{cartItemText}</span>
<span class="items">{cartItemCount}</span>
</button>
And below is the CSS for the visually-hidden class:
.visually-hidden {
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}
This way you have interactivity, text displayed in numbers for visual users and also text read out aloud for screen reader users.
Let's take an Open Library list page for example. When you visit the page, one of the first things that a user with a screen reader would hear is "link, Mek". Mek is the username. However, in the case of social websites someone could pick any username like "borrow the book" or things that I imagine would be disorienting to people using screen readers.
So, my question is, would it be appropriate to use something like aria-label to say that it is a username since that is not otherwise written on the page? If not, is there another way that people using screen readers deal with this?
I'm new to A11Y and ARIA so maybe I'm looking in the wrong place for answers. I have tried searching this in may ways and read some documents like Using aria-label for link purpose and Using aria-label to provide an invisible label where a visible label cannot be used.
I also looked at the code on social sites such as Twitter, Reddit, and Facebook but as far as I can tell none of do anything special for usernames. Perhaps it is less important for sites that are primarily user generated content.
Linked Example
In the example page you linked those are actually breadcrumbs so technically make sense.
<div class="superNav">
Mek
/
Lists
</div>
With that being said they should be located within an unordered list (as an unordered list is useful for screen reader users to know how many links there are as it will read "1 of 2 option" or similar) and have some form of identification on the <nav> (so it is not considered main navigation):
<nav aria-label="breadcrumbs" class="superNav">
<ul>
<li>
Mek
</li>
<li>
Lists
</li>
<ul>
</nav>
Finally if you have a sophisticated back-end or the first link will always be a link to a user profile then you could add some visually hidden text to the link just for clarity.
HTML
[...]
<ul>
<li>
<span class="visually-hidden">User Profile for </span>Mek
</li>
[...]
CSS
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
Social sites
However for social sites there are loads of things you can do.
For example if the image is a link to their profile you can use the alt attribute to indicate the action of the link.
<a class="profile-container"
<img src="profile-image-user-rayb.jpg" alt="RayB profile page" />
</a>
If it is just a static image (and their username is not shown anywhere else) then the alt attribute would change with the context.
<img src="profile-image-user-rayb.jpg" alt="RayB profile picture / avatar" />
If it is a static image and the persons name is located somewhere else within that article / block then you would likely hide the image:
<article>
<h2>Some article Title</h2>
<img src="profile-image-user-rayb.jpg" alt="" role="presentation" aria-hidden="true"/>
<p class="written by">Author: RayB</p>
</article>
** please note:** in the last example an empty alt attribute is sufficient to hide an image from a screen reader. I add role="presentation" and aria-hidden="true" so that I can check for empty alt attributes that are mistakes (e.g. if they do not have aria-hidden="true" then I know they should have an alt attribute filled in).
Why so many variations?
This is where accessibility turns from a set of rules into an art form, you have to pick the best option depending on the circumstances.
A good place to start for alt attributes for example is the alt text decision tree from W3.
Other than that consider things like:
does this add additional information a screen reader user needs?
Is the information available elsewhere / nearby and does this then just duplicate it?
If this is an image in a link does the alt attribute reflect the action of the link in context. etc....
Above all, grab a screen reader and try it, that is without doubt the quickest way to learn (as you can identify an issue / something that confused you / repetition etc. and then it is easy to look for a fix/).
If you need more info just let me know!
We are using Coveo for their elaborate search capabilities on top of Sitecore CMS.
The filter facets to narrow down your search results generates a list of checkboxes with a <div> tag, and each of these along with text next to it is inside a <li>, which as a group are inside a <ul> (code sample below). Visually appears like so:
Had to use jQuery to add my own attributes to make sure div.coveo-facet-checkbox was recognized/read as a checkbox by screen readers, which is working quite well with NVDA and ChromeVox.
However, JAWS has a slight issue that once focus moves into the <ul> list, the first div.coveo-facet-checkbox it will land on, JAWS will first announce "readonly".
Code sample:
<ul>
<li>
<label>
<div>
<input type="checkbox" form="coveo-dummy-form" style="display:none;">
<div class="coveo-facet-checkbox" tabindex="0" title="Education and Events" role="checkbox" aria-checked="false"></div>
<span class="coveo-facet-value-caption" title="Education and Events" data-original-value="Education and Events" aria-hidden="true">Education and Events</span>
</div>
</label>
</li>
<li>
...(structured same as above <li>)...
</li>
</ul>
I have tried to add the attributes readonly="false" and aria-readonly="false" on ALL tag levels of code sample shared, and still JAWS chooses to announce "readonly"
Not sure what else to do/try. Tried to search online, but only found people complaining about similar sitiations, but with not fix/solution.
Any tips/tricks for me to try out would be appreciated.
NOTE: Sorry if I cannot respond right away as I won't get much chance to be on computer until Monday (will edit this last line out when back).
Screen readers themselves are not 100% perfect and was able to trace this to the fact that the checkbox is inside the <li>.
Just by changing the role attribute of the <li> would change how the screen reader would announce when focus went to the checkbox.
So now to just decide which role to use. I came across role="none" which JAWS does support, but NVDA does not. However, since this is a JAWS specific issue, this seems like a good choice.
To apply changes like this after results are rendered by Coveo, the deferredQuerySuccess was used to improve the checkbox div:
// When Filter Facets are rendered.
Coveo.$$(document.body).on('deferredQuerySuccess', function (e, args) {
// Set role for each li parent of Coveo's <div> checkboxes
// to prevent JAWS screen reader from saying 'readonly'
$('.coveo-facet-value.coveo-facet-selectable').attr('role', 'none');
});
NVDA reads correctly. JAWS read only Link 1, Link 2 (content is Link 1, Link 2), but do not read that is is a list
list-style-type: none;
html:
<ul role="list" class="content-links">
<sly data-sly-list.link="${model.links}">
<li role="listitem">
<a href="${link.href # context='html'}" aria-label="${link.label}" rel="${link.rel}"
tms-dblclick="${link.tracking.tmsDblClick}" data-pid="${link.tracking.vadm.pin}" data-pid-action="${link.track.vadm.pinAction}">
${link.label}
</a>
</li>
</sly>
</ul>
Your code is correct (other than the superfluous roles you have specified, as pointed out by #shannon). Unfortunately, that's just how JAWS works. When you tab to a link that is contained in a list, the link text is read and the fact that the link is contained in a list is not read. But if you navigate the DOM using the up/down arrow keys in JAWS, when you navigate to the link, you will hear "list of 3 items" before you hear the link text. And you'll hear "list end" when you arrow down past the list. Native JAWS users are used to it (not that that makes it the right user experience.)
The link text should provide enough information by itself for a user to know what will happen if the link is clicked. JAWS users can find out that the link is part of a list if it's relevant. Don't worry that JAWS doesn't mention that it's in a list as the user tabs through, as this isn't expected behaviour.
There is a drop-down in my web application. This drop-down is user-defined (not using the <select> element). Inside this drop-down there is a down arrow. This arrow is creating by using background images on an absolutely positioned span. This span tag is blocking the click event of the drop-down. So, I've added pointer-events:none to the span tag. After adding this, it's working fine everywhere but in the Edge browser. Does Edge support pointer-event: none? If not, what is the alternative for pointer-event: none in Edge.
Below is the code which I used:
<div class="multi-dd" id="multi_dd_ddlProfession" role="application" cascadesto="ddlDiscipline">
<input class="multi-dd-txt" id="txtProf" role="combobox" aria-readonly="false" aria-describedby="spMultiExit" style="width: 260px;" aria-label="Multi Select Control Professions " type="text" readonly="readonly" value="Select All">
<span class="nir"></span>
</div>
.nir{
height: 28px;
margin-left: -30px;
vertical-align: bottom;
overflow: hidden;
pointer-events: none;
}
There are some bugs which may be the root cause:
FocusEvent Sequence should be: focusout, focusin, blur, focus.
FocusEvent Sequence is: blur, focusout, focus, focusin.
and a no-repro test:
#testID {pointer-events: none;}
<ul>
<li>MS Dev</li>
<li id="testID">example.com</li>
</ul>
The first version of Microsoft Edge was introduced in Windows 10 Build 10049. Pointer Events have been supported since Windows 10 Build 10240.
References
"Project Spartan" in the Windows Technical Preview build 10049 – IEBlog
Windows 10 Build 10240
RemoteIE - Microsoft Edge Development
HTML5test - How well does your browser support HTML5?
CSS 'pointer-events: none' rule not working
DOM Level 3: FocusEvent sequence
Edge raises "blur" event while "click" event processing is not completed
Problem with focus
Click event not raised when Edge is not in focus
Unifying touch and mouse: how Pointer Events will make cross-browsers touch support easy – David Rousset