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.
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).
Right now I am setting the focus on the very first editable input field, during page load.
In terms of page accessibility, If the very first element is "read-only" input field then is it valid or meaningful to set the focus on the input field with cursor disabled ?
The question you should be asking is should you interfere with the user focus at all?
You may think it useful to automatically focus the first input (whether it is read-only or not) but this may not be as useful as you think.
When the page loads the user is expecting to have to use your skip link (I assume you have one, if not add it) to bypass the menu and get to the content of the page. However they may not want to as they may want to check they are on the correct page through breadcrumbs, menu position (assuming you mark the current page in some way) etc.
I am also assuming you have a <H1> on the page to reinforce that they are where they think they are on the site so they would expect to see that also.
If they are filling in a multi-page form then they will use screen reader shortcuts to look for the next form, if you have more than one on the page (search box, quick contact etc.) they would end up navigating away from your form by mistake instead of landing on it.
Now assuming that even with all of the above it is actually a better user experience to focus the first input (I am not saying it isn't, just pointing out the above considerations) should you focus the first 'read-only' input.
The answer is nearly always yes.
If a non screen reader user will see that information before they see information that requires inputting / editing then a screen reader user should also see it first.
The only exception to this would be if all of those read-only fields are a summary of everything entered so far in a multi part form.
In that case (as a rough rule, yet again use your own judgement) you should still provide that information first but make sure there is a heading / legend / field set title etc. that indicates that this is previously entered information and provide an easy way to skip to the fields that require input.
It is perfectly acceptable to have 'skip links' within the document, they don't have to just be for menus.
You do this so that they have the option to check previously entered information is correct and know it is available on the page to refer back to, but also don't have to tab past every single field if they don't want to check the information entered previously.
As with everything in accessibility, each use case is slightly different so the only real answer is 'it depends', but hopefully the above will help guide your thought process on what will work best.
This is where user testing is your best friend, only real world screen reader users who do not know your site design and layout will let you see if you made the best choice / which scenario works best.
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.
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>
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.