When we use the tab key to cycle through the <a>, <input>, <select> elements across the page the NVDA reader will call out the inner text. Is there a way to markup the code so that it picks up and reads headers 1-6?
It seems a bit of a hack to wrap the headers around an <a>, is there any other solution?
I tried to add a aria-label attribute but that was just shooting in the dark.
I would say this is not a good idea. People with mobility disabilities will find the page combersome to use, maybe even annoying, since you are adding more things to tab through.
NVDA and other screen readers have built in hot keys to allow users to jump to or cycle through the headings. A user can press H to jump to whatever the next heading is, or they can press 1-6, to jump to a specific heading level.
If you still want to do this, you can do:
<h1 tabindex="0">This is a header</h1>
Related
To improve accessibility, what role should I use for completely unrelated content such as a forum signature? Since it's completely unrelated to the main content and would frequently repeat, I thought it might even be a good idea to use aria-hidden="true" on it to make the experience of reading a forum thread with a screen reader more fluid, although according to MDN, aria-hidden "should not be used on a focusable element".
Based on the comments there are two things I would implement:
Item 1 - a <footer>
Put the signature in a <footer> element, it is the most appropriate element for if you are using <article> for each post.
I would also suggest you put an aria-label on each footer that says something like aria-label="signature for {username}" just to make it clear to people who use a screen reader.
Item 2 - keyboard navigation
People who use a screen reader will be fine if you have structured the page correctly and able to skip between posts without having to always listen to a signature.
However for keyboard users who rely on the Tab key I would recommend adding keyboard shortcuts to jump between posts so they don't have to keep tabbing past signatures.
An easy way to do this would be to implement keyboard shortcut keys for jumping between posts. "J" and "K" are widely used keys for previous and next items.
However I would also suggest a way to switch this feature off, just in case it interferes with a screen reader (as "k" is "next link" in most screen readers).
Is the following HTML accessible?
<a id="myClickbaitArticlePreview" href="someUrl">
<h3>Amazing lifehack! Doctors hate him!</h3>
<img alt="doctor is staring down a patient" src="procativeThumbnail">
<p>Compelling copy</p>
</a>
I know it's valid based on this answer. But is it accessible? Cause I am auditing a website with a similar article structure using a screen reader (JAWS). The reader reads everything in a single breath which is confusing (but I am not blind so I don't know if you get used to it). It also reads the alt right after the title, which in many cases may repeat the content.
Short Answer
It is both valid and "accessible" in the loosest sense of the term, a good experience for screen reader users - probably not.
It would pass all WCAG guidance, let's put it that way.
Longer Answer
Without seeing it in the context of the page though it is hard to tell you whether this is the best practice. A few things to consider:-
Is there sufficient white space around these large "link cards" for people with mobility / accuracy / dexterity issues to safely place their finger to scroll the page on a mobile device.
If the link card is focused is the focus indicator easy to see and sufficient contrast etc. (standard thing to check for but often forgotten on card type links)
If a screen reader user cycles the page via headings is it logical to have a <h3> in the card, both in terms of heading hierarchy and in terms of page hierarchy.
Are the alt descriptions correct in their context, if the image is not directly related they may be better being hidden from screen reader users with aria-hidden or an empty (not null) alt attribute (alt="" NOT alt). I would almost certainly say this will be the case but yet again that is your judgement.
alt being the same as the <h3> title - this is almost certainly a big no no. alt attributes should describe the image in context. If the alt text is the same as the title then make the image presentational / hidden from screen readers as discussed in the previous point.
Should these be <article> elements to be semantically correct?
Are they contained in an <ul> so that a screen reader user knows how many items there are?
would an aria-label on the hyperlink with a condensed version of the text be appropriate (to override the text inside the hyperlink)? It depends on the content so use best judgement.
Would a hyperlink styled to look like a button at the end of each article be better? If so make sure it doesn't just say "read more" (although at a push you could have "read more" as the button text and have some visually hidden text that says "Amazing lifehack! Doctors hate him!" before it).
As you can tell, without seeing them in context there is lot's of things we cannot tell you but hopefully the above should give you a few things to think about.
As for the screen reader reading everything in a single breath, that is expected behaviour, you just need to get used to it! You could always slow the speech rate in the settings or increase the announcer verbosity (so it has more detail about what element you are in relative to other elements) while you get used to it.
According to HTML standards, the a element has a transparent content model with the sole exception that it can't contain interactive elements.
An heading is not an interactive element. So that's good according to the standards.
Regarding accessibility the text link is not optimized.
WCAG in 2.4.4: Link Purpose (In Context) expect a "meaningful link". Having too much information is not a good practice. A better alternative would be to provide a javascript click handler on a <div> while only having the HTML link element on the h3 here.
In your example "doctor is staring down a patient" does not describe the link destination and should not be part of the link text alternative.
Hello to the community!
I'm currently trying to enhance a website with good accessibility practices.
I have some concerns about a page that lists a huge amount of repeated results blocks, each having 5 links.
When navigating with the keyboard, jumping from one block to the other requires 5 tabs, which is really painful. So I thought about a hidden select dropdown that creates anchor links to the right block.
The select works like a charm, but has some usability or design issues:
If hidden, this makes an "empty" tab for sighted users.
I tried to totally hide it but when focused, the options are force-shown by the browser. This makes weird behaviour for sighted users if they accidentally open it (via a tab, seen on first point).
I tried to push it out of the viewport (left:-999px or via div overflow hidden) but Chrome then makes it unselectable.
Showing it from the start makes the design ugly. (Having a solo select in the middle of the page is not really friendly.)
And overall, I try as much as possible to keep the page light and sustainable and avoid, as much as possible full JS features.
What is your opinion about this? Do you have any other ideas that would fit? Any insight would be invaluable!
Thank you!
--- EDIT ---
I added here the global structure of the results list (I don't go in details but main repeated elements are here):
<section>
<h2> Nb of results + query </h2>
<!-- first idea : add a select here -->
<ul>
<li>
<!-- second idea : add hidden link here with focusable switched -->
<h3>
<a> Result name</a>
</h3>
<p> description </p>
<a> link 1</a>
<a> link 2</a>
<a> link 3</a>
<a> link 4</a>
</li>
<!-- repeating this li more than 10 times -->
</ul>
<!-- pagination goes here -->
</section>
<aside>
<!-- aside content -->
</aside>
As you have seen yourself, having form fields or dropdowns hidden and be shown on focus isn't a good idea, as it is suceptible to create functional bugs or unwanted visual effects.
Additionally, it isn't likely to be of much help. Screen reader users aren't tab-only users. I'm a screen reader user myself, and we have much more efficient ways to go to the information we are interested in than just repeatedly press tab (read further below).
Only big beginners do that.
Tab-only users are more likely to be sighted. They may benefit from the dropdown, but of course only if it is always visible.
For screen reader users, I would rather recommand adding the appropriate tagging in order to group the items:
There are several approaches to do that:
Use headings H1-6
Use <article>, <section>, another tag of that sort that automatically creates landmarks, or use ARIA to create landmarks yourself.
Use lists, definition lists and appropriately nest
Screen readers provide special shortcuts to navigate heading by heading or landmark to landmark. In fact we can, and we abuse of that whenever we can, use those shortcuts to quickly skip blocks we aren't interested in.
This little list above is by order of preference. Headings are better than landmarks because landmarks have been added more recently, and thus many of use are still used to look for headings first.
Nested lists are less good because it's harder to skip uninteresting parts, but it's still better than nothing if you have no solution to properly add headings or landmarks.
Look at Google search results as an example. Each result is an heading.
If the heading says everything and tilt immediately, it's also a link we can directly click on. If we aren't sure, we can read the description just below or access to additional options. If we aren't interested in the result, we can just press the shortcut to go to the next heading and so we have quickly skipped that result we aren't interested in.
Not sure what you mean by 'results blocks', but tabbing past repeated navigation on every page is a familiar nuisance in the a11y game.
Some kind of hidden 'skip to main content' feature, which appears as one of the first tab stops (before the navigation) is a very common solution to this kind of problem. Do a web search for 'accessibility skip to main' and you will find many suggestions. Yes, you'll probably need a little javaScript to focus and reveal the hidden link.
If you have non-interactive content on the page, screen reader users have special tricks to reach it quickly without all that tabbing. You could also consider using landmark roles or even custom keyboard shortcuts to navigate within the document.
If you are worried (point 2) that sighted users will get to see an ugly widget when they accidentally press Tab, then... make it beautiful.
I am working on creating accessible help text for my form controls. I am planning to use aria-describedby to attach a accessible description to a field. This approach is discussed here
Although in my testing with ChromeVox extension and Windows 10 screen reader I have found out that aria-describedby is not announced, but it is rather well supported across browsers and screenreaders, so i am planning to use this approach.
Also this suggests that in some cases aria-describedby would be ignored or not work as expected but these cases are quite specific and i am generally ok with it.
aria-describedby content may not always be announced to users,
depending on their screen reader and navigation method. The attribute
is well supported, but that doesn’t mean there aren’t some things to
be aware of: aria-describedby content may not be announced by all
screen readers if navigating to a button, link, or form control with
the virtual cursor. JAWS specifically may not announce an element’s
description when using hot keys to navigate to certain elements. When
navigating by visited links, the description will not be announced.
However JAWS should announce descriptions when navigating by form
controls. JAWS 17 + IE won’t announce aria-describedby content when
tabbing to a link (newer version of JAWS have fixed this). IE11 won’t
announce the accessible name or description of a form control if the
title attribute is used in tandem with aria-describedby, and the
user is navigating by virtual cursor or form control hot key (F). Both
will be announced if using the Tab key. (IE11 had much bigger problems
with aria-describedby in the past.) TalkBack + Android Chrome won’t
announce any aria-describedby content of a modal dialog when
auto-focusing an element within that dialog. If a user has
descriptions or hint text turned off, any associated content won’t be
announced. Because of this, it’s vital that any content that is
necessary to the understanding of a UI be available by means other
than just aria-describedby.
I would like to understand if there are times when aria-describedby would not be announced automatically? The previous link phrasing seems to suggest that it is only going to be announced on request :
By using aria-describedby to reference the format of the field, this
information is made available to the users on request. That is, it is
not automatically displayed or read aloud. This makes sense if the
user has been informed of the format before, or when there are lots of
input fields with the same format, for example.
I don't get what it means by "on request". I believe that the default behavior is to announce the aria-describedby text after announcing the label and the input type.
The behavior of aria-describedby (like aria-label and aria-labeledby) is profoundly influenced by the role of the element where they appear.
As you may know screenreaders generally have two 'modes', and this is mostly determined by the role (or default semantics) of the content.
I have certainly had problems getting non-interactive elements announced, if they appear within interactive ("forms mode") content.
I have had good results using aria-describedby with modal content. (Put the attribute on the modal, and point at the text elements inside which you want announced when the modal opens.) But I suppose this is because there is an obvious moment where the screenreader is supposed to make those announcements: the moment when the modal opens.
In the case that the form (or other "forms mode" container) is always present on the page, you can usually read the non-interactive content using browse-mode key combinations such as "next heading" ("H" on NVDA and JAWS) or "next paragraph" ("P"). Check to see if these 'requests' are enough of a solution.
You might also experiment with the standard HTML elements fieldset and legend, whose purpose is providing a text description for groups of interactive elements.
Also consider treating the 'form' (or toolbar or whatever) as a single tab stop, and use arrow keys to navigate the components within. This way, when you give focus to the container, you should get an announcement of whatever is aria-describedby (or indeed aria-labeledby/aria-label)
If this isn't working for you, there are a couple of hacks you might try as a last resort:
Put tabindex="-1" on the element surrounding the text you want
announced, and then call focus() on that element at the appropriate
moment.
Copy the text into the textContent of an aria-live region
with javaScript at the appropriate moment.
Neither of these hacks are pretty, and might not suit you, if there is no 'appropriate moment'. (There's no equivalent of onfocus for browse mode). But with a little care, they can be made to work.
Please correct me if I am wrong, but usually screen reader navigation works by pressing the tab key, and usually you do not have (or need) tab-able images. Therefore, when is the alt text actually useful to the screen reader?
I have seen examples where the screen reader reads things when pointed/selected by mouse (mostly for testing), but I am not sure if that is a practical usage.
(Another scenario that comes to mind is link images where the alt text might be used for link description.)
Please help me with more info.
usually screenreader navigation works by pressing tab key
Typically only interactive items - links, buttons, and the like - are accessible by tabbing. But screenreader users need to be able to access all content on the page - not just the interactive items. Think of how useless a wikipedia page would be if you could only read out the links on it, and none of the content.
Screenreaders generally provide a set of tools and commands for navigating a web page:
The simplest approach is to move linearly through the page, item by item. This will cover everything: non-interactive items, interactive items, text, images, everything!
The user can also navigate between items of a similar type - from one list item to the next, or from one table to the next, or from one image to the next
There are generally also commands to navigate the heading structure (H1...H6).
Users can also search for specific text on the page, and then continue reading or exploring from there.
Check out this list of shortcuts for common screenreaders from accessibility specialists Deque.
Several screenreaders intercept and capture most keyboard input while the user is using them: if you're using JAWS or NVDA, for example, hitting the down arrow key causes the screenreader to move to the next item instead of causing the browser to scroll down. Likewise, hitting H causes the screenreader to move to the next heading - the browser never sees that keypress. (If you tab to an input field, however, the screenreaders will let the input go through.) On the Mac, the VoiceOver screenreader instead uses keyboard modifiers for its commands - or example, Control+Option+RightArrow moves to the next item.
Using a screenreader to navigate and read a page is perhaps a surprisingly interactive experience: you're not just listening to what the screenreader is reading out (or equivalent if using Braille), but using commands to tell it where to navigate next. A user might start off reading down through the initial part of the page to see what's there, then switch to heading navigation to see what the overall page structure is and find a specific section, then read through that item by item. If the user is familiar with a page, they might use the search command to find some well-known piece of text and jump straight there.
This isn't all that different than how sighted users might view a page: visually scanning the top level structure, reading the headings, and then reading a particular section. But whereas most sighted users take this process for granted, when using a screenreader, you have to do it manually.
Please correct me if i am wrong, but usually screenreader navigation works by pressing tab key, and usually you do not have (or need) tab-able images
Yes this is wrong.
WebAIM publish the list of shortcuts for NVDA or JAWS
The tab key is only used to "Navigate to Next form Control".
You have different shortcuts to read the text, and the alternative text will be spoken when reading an image.