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).
Related
I currently have a simple bit of markup on my site, and can't seem to get a screen reader to read it. Am I missing something?
<section aria-label="This is the text I want to be read "></section>
I've also tried:
<section aria-description="This is the text I want to be read "></section>
The section isn't tabbable as such as its not a link, not sure if that's connected to the problem, but my understanding of whether the screen reader should or should not be reading something is sketchy at best.
Screen reader in question, if it matters.
https://chrome.google.com/webstore/detail/screen-reader/kgejglhpjiefppelpmljglcjbhoiplfn
Any help appreciated.
It might depend how you are navigating with the screen reader. Since the <section> is not a keyboard focusable element, I'm assuming you have some text content in it? Most screen readers will let you navigate to all elements on the page, including plain text, using the down arrow. The down arrow essentially walks the DOM. (It actually walks the accessibility tree but for now think of it as walking the DOM.)
If you can navigate to a focusable element before the <section> using the tab key, then you can start using the down arrow to get to the section.
With NVDA, I heard "This is the text I want to be read, region". Note that it's saying "region" because a <section> element has a default role of "region".
With JAWS, it did not read the aria-label, but that's because of the JAWS default verbosity settings which does not include regions. If you change your verbosity setting from the default "medium" to "high", then you will hear the section label when you arrow down to it. (Or you can configure your current verbosity setting to include regions.)
With JAWS, you can also navigate by landmarks. Since a <section> has a "region" role, and a region is a landmark, I can navigate by landmarks with JAWS using the R key and when I do that, I hear "This is the text I want to be read region", regardless of my verbosity setting.
So, as someone else posted, if you use a "standard" screen reader, the label will be read. If you use a lesser known screen reader, then it's hard to say what will happen.
Regarding aria-description, that's not production yet. It's part of the ARIA 1.3 specs which is still in draft form. The production ARIA 1.2 does not have aria-description so it's doubtful it will be read.
ACcording to ARIA specification, the <section> can perfectly have the aria-label attribute.
Most other HTML5 structural elements also allow aria-label because they are landmark regions.
So, conforming screen readers are supposed to read it, and, as far as I have tested, they indeed do.
Attribute aria-description is more recent than aria-label, so you should prefer aria-label in order to maximize the chances to have it read.
IN order to make good and relevant tests, I suggest you to use a true screen reader really used by users, rather than a browser extension that nobody use in the real life.
You may try one or more of the following, depending on your target systems and possibilities: (Non exhaustive list)
NVDA, Jaws and Supernova under windows
VoiceOver under MacOS, iOS and iPadOS
Talkback and VoiceAssistant under Android
NVDA, VoiceOver and Talkback are totally free, and VoiceOver is even always available out of the box without the need to install anything. So you really have no reason to don't try them out.
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.
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.
I use "read more" at the end of paragraph just for reminder for user same like P.T.O
Why it's problematic?
You have to understand that many screen reader users don't wait for the whole page to be read to them. They use keyboard shortcuts to navigate around the page. JAWS (arguably the most common of screen readers) has several very useful shortcut key combinations. One in particular pulls up a list of all of the hyperlinks on any given page. This way the user doesn't need to wait for the reader to get to the section of the page they're interested in before finding out what kind of links the page contains. They can just use the shortcut and get a list of links all at once on demand.
It's when using the list of links shortcut that your "Read More" links are completely useless. When viewing a huge list of all the links on the page, the user is simply read the text inside the tags. There is no context. The user has no idea what preceeds or follows the "Read More" text. All they know is there's a link for them to "read more" about something. This gets especially confusing when there is more than one link like this on the page. The user also does not generally listen to the URL, as that's pretty much worthless given all the insane query strings and the computerized voice struggles with reading URLs.
Does that help answer your question?
As a screen reader user and an occasional web designer (not to mention a web accessibility consultant), sometimes ambiguous links are unavoidable. While it's not always convenient for a screen reader user to figure out the context of a particular ambiguous link, it's not that much of a burden to figure out one or two. The problems come when pages are loaded with them.
When making this decision, you really need to consider if the extra wording in the link is too high a price to pay for the convenience to a screen reader user. Usually, with a little thought, you can come up with a link text that is better for everyone. However, just keep in mind that if you do have to use ambiguous link text, you won't "break" accessibility, just make it slightly less convenient for some. On the spectrum of "must haves" to "nice to haves", this is well within the latter half, unless ambiguous links become the rule, rather than the exception.
This blog entry discusses the drawbacks of 'click here' links. Another drawback of 'click here' links is they do not help identify keywords to that might be associated with their target... think SEO.
I'm a web developer, and I want to make the web sites I develop more accessible to those using screen readers. What limitations do screen readers have that I should be most aware of, and what can I do to avoid hitting these limitations.
This question was sparked by reading another question about non-image based captchas. In there, a commenter said that honey pot form fields (form fields hidden with CSS that only a bot would fill in), are a bad idea, because screen readers would still pick them up.
Are screen readers really so primitive that they would read text that isn't even displayed on the screen? Ideally, couldn't you make a screen reader that waited until the page was finished loading, applied all css, and even ran Javascript onload functions before it figured out what was actually displayed, and then read that off to the user? You could probably even identify parts of the page that are menus or table of contents, and give some sort of easy way for those parts to be read exclusively or skipped over. I would think that the programming community could come up with a better solution to this problem.
Are screen readers really so primitive that they would read text that isn't even displayed on the screen?
What you have to remember is that any HTML parser doesn't read the screen - it reads the source markup. Whta you see on the screen is the browser's attempt to apply CSS to the source code. It's irrelevant.
You could probably even identify parts of the page that are menus or table of contents, and give some sort of easy way for those parts to be read exclusively or skipped over.
You could, if there were a standard for such a thing.
I'm not very hot on the limitations of screen readers, however I've read a lot about them not being ideal. The best thing I can reccommend is to put your source in order - how you'd read it.
There are a set of CSS properties you should also look at for screen readers.
Recommended listening: Hanselminutes
It's an interview with a blind programmer.
How many forms just have a * or bold to indicate to a sight user that a field is required for correct submission? What's the screen reader doing? Saying "star"?
Below is an example of code that is helpful by articulating verbally but not visually.
(note - in the example below the word "required." is spoken but not seen on screen)
In the template:
<label for="Requestor" accesskey="9"><span class="required"> Requestor * </span><span class="hidden">required.</span></label>
In the CSS:
#hidden {
position:absolute;
left:0px;
top:-500px;
width:1px;
height:1px;
overflow:hidden;
}
or
.hidden {
position:absolute;
left:0px;
top:-500px;
width:1px;
height:1px;
overflow:hidden;
}
There can be a whole parallel view behind the "seen" in every X/HTML page.
#robertmyers
CSS contains the aural media type specifically to control the "rendering" of things when screen readers are doing their work. So, for you example, you would only set it as visible for the aural media type.
#Ross
I'm quite aware that the screen reader doesn't actually read the screen, but you would think that to work well, it would have to build a model of what a person with sight would see, otherwise, it seems like it would do a really poor job of getting across to the user what's actually on the page. Also , putting things in the order you would read them doesn't really work, as a sighted person would scan the page quickly and read the section they want to read. Do you put the contents first so that the user has to listen to them every time, or do you put them at the end so that they can get to the content first? Also, putting content in order would mean some tricky CSS to get things positioned where you wanted them to be for sighted users.
It seems to me that most web pages contain very similar construction, and that it should be possible to, in many cases, pick out where the repeated headers and side columns are. When viewing many subsequent pages on the same site with the same formatting, it should be easy to figure out which sections are navigation, and which are content. Doing this, the screen reader could completely skip the navigation sections, and move right onto the content, as most sighted users would do.
I realize there are limitations, and that doing these types of things wouldn't be easy. However, I feel like as far as screen readers go, we only did the bare minimum and left it at that.
Have a look at ARIA, it's a standard for developing accessible rich-web-client applications.
#Kibbee,
What you are describing as "primitive", is in fact a feature of screen readers that can be, and is, used to make sites more accessible. For example, if you have a tabbed interface, implemented with an unordered list and list items, then the sighted user would normally see the selected tab highlighted with a background color that is different (or some other visual treatment). Blind users cannot see this. So adding some additional text into the page and hiding it off screen is the technique used to communicate to the blind user what tab is active.
In the accessibility lingo, this information is known as role, name, value and state.
There are many other scenarios where this technique can be used to add information that is useful for a blind user.
More recently, WAI-ARIA has been added to allow this state, role, name and value information, so you can now implement a limited number of widgets (like tabs) using HTML attributes. However, the more general "off screen" technique is still useful.