If I have an element that has the aria-live='polite', but I don't want the screen reader to reads the updated content, but a customized message I provide, is it possible?
Thanks!
Adding content to a live region when you don't want it announced goes against the design of the ARIA live region specification, so I'd encourage you to think this through before proceeding with whatever you're doing here, but for purposes of this question I'm going to focus purely on what is and isn't technically possible.
You could, in theory, add aria-hidden="true" to the content in the live region that you don't want announced. This will prevent this section of the DOM from being exposed to the accessibility tree in the browser. At the same time, this content will be visible to sighted visitors.
On the flipside, you can add content to a live region that isn't visible to sighted users. This would be the "custom message" that you describe. The usual technique for this would be to position the content off-screen using CSS.
Related
I have a complex multi-column form that the NVDA screen reader reads perfectly well after the page loads, including aria-labels, fields, order of elements, etc. In this working scenario, the form is fully visible when the page loads.
However, I need to hide this form by default when the page loads. This form should only appear if the user clicks a "Show form" link on the page, setting the form from "display: none" to "display: block".
By default, the reader won't automatically read the form after I click "Show form".
So I added aria-live="polite" to the form. The reader will read the form when I click the "Show form" link, but the reading is very poor - things gets mixed, aria-labels get ignored, the reading flow breaks, etc.
So my question is, using a screen reader like NVDA, how do I get a clean and accurate reading of an element that goes from display: none to display: block (based on some user interaction) after the page is loaded?
As I mentioned above, I get a perfect reading only if the form is visible when the page loads.
Aria live regions are only read in two occasions:
When they are added in the DOM
When their content changes
IN all other cases, it isn't officially specified if they must be read or not. They are with some browsers + screen readers combinations, but not with some others.
IN any way, it isn't a good idea to read an entire form section.
If the user can quite well expect something to appear, it's much more important to make it naturally reachable, than to announce the fact that it appeared. By naturally reachable, I mean both by tab and by browser cursor commands like arrow keys or navigation from form element to form element.
In particular, it means that you should for example avoid adding new content at the end of the body, but rather add it in the DOM where it is really expected instead.
Once this is correctly done, at that moment you may think about announcing that the form section appeared. You shouldn't make the whole new section being read, but stick to a simple general message, like "Personal information section appeared below general information". This kind of message has to be in an aria live region.
If that form section appears quite unexpectedly from the user point of view, this announcement can be really useful. If what happens is quite expected, that announcement is relatively optional, if you have made it appear at the right place.
Above you se a typical breadcrumb.
Sometimes there are to many steps in that breadcrumb, so we have to shorten it by replacing some of the steps in the middle and display three dots instead
When a user clicks on the three dots, the entire breadcrumb is visible.
How would you handle the accessibility issues here?
We would like to show all the steps to our screen reader users so those users can tab trough the entire breadcrumb whiteout ever knowing about those dots.
All other users will only be able to see those tree dots.
We can accomplish this in a few ways:
Use display:none but this will hide the hidden content for all users, including screen readers
We can use the class.sr-only (since we're using Bootstrap) or something similar on those hidden links so only users with screen readers will se the hidden parts of the breadcrumb. This will work, but it will remove the hidden parts breadcrumbs from the tab order.
We can stick to #2 above and add taborder="0" to those hidden links in the breadcrumb, but then we also have to add taborder="0" to every single interaktive element on the entire site and that is NOT an option. :-)
Are there any other ways to include the hidden links in the tab order?
(Sure, one can discuss the UX aspect of abbreviating a breadcrumb, but that's perhaps another topic.)
(Sure, one can discuss the UX aspect of abbreviating a breadcrumb another topic.)
This is perfectly the topic.
Blind person are normal people who like simple things. If you think your breadcrumb is too long, give them the same functionalities :
<button aria-label="view full breadcrumb">...</button>
Breadcrumbs have not been invented for blind people. They are part of one technique in a WCAG AAA guideline which implies that : it's not mandatory, and that it concerns everybody.
If you include hidden links in the tab and speech order, you are sure that your website won't be accessible.
A near-blind person using a screenreader in support of his eyes won't be able to view a link on the screen while it's announced by the screenreader.
A person using a keyboard only system will focus an invisible link which will remove the predictability of the focus order.
Note that for 2/ and 3/ the sr-only does not remove the elements from the tabindex, so this will work as you would expect
I'm working on a site that requires WCAG 2.0 AA adherence, but although we try to make tab navigation usable on our sites, it does detract heavily from the design due to the strange borders and outlines being rendered when you click a focusable element.
My thinking is, hide all focus states until the tab key is actually pressed.
So, my question is, does this pose any potential problems with accessibility technologies for the web?
Remember that sometimes focus is placed on elements without using a keyboard, such as via script or third-party tools (like screen readers prior to page interaction). Also note that even screen reader users do not necessarily use the Tab key (for example, I can navigate the headings on a page by pressing H in most screen readers, and on mobile I can navigate a page elements without using a keyboard at all. Also note that some users with cognitive impairments benefit from focus styles even when using a mouse.
As such, if I were reviewing a site that disabled focus styles only until someone pressed the Tab key, I would still fail it for 2.4.7
Focus Visible. It might be helpful to read the Understanding SC 2.4.7 document for a little more context.
To answer your question, yes, removing it does post potential accessibility problems.
All that being said, I would instead challenge the designer to do what designers tend to do best — work within constraints. Come up with focus styles that are not distracting, with styles that are perceivable, operable, understandable, and robust (so, for example, it meets contrast minimums). It has been done before, so there is no reason it cannot be done again.
Accessibility is important to me as I'm a physically disabled developer. I'd like to make sure I have a good feel for what it takes to make a site accessible while also being pointed in the right direction for the things I'm uncertain with, or just haven't considered. So, here's what I'm comfortable with right now:
Alt text for images with meaning.
Percentage or font-relative measurements (ems) for those who need to re-size their screens.
Colors with good contrast for those with colorblindness.
Textual representation of any audio/visual material.
Questions:
Should I make a link at the top of the site to jump down to content on every page?
How is JavaScript handled by screen readers?
Is there anything major I'm missing?
WebAim.org is a great resource for all things web-accessibly related. Suggest starting off with their WCAG (Web Content Accessibility Guidelines) checklist.
Quick answers to your qu's:
Should I make a link at the top of the site to jump down to content on every page?
This is currently recommended best practice. (Eventually HTML5 semantic tags will remove the need for this, but we're not there yet. One thing to watch for: if you do use a hidden link, be sure to make it visible again when it has focus, so that sighted keyboard users don't get 'lost'.)
How is JavaScript handled by screen readers?
All depends on what you use it for. The main area for problem is if new content appears that the user is supposed to be aware of (eg. popups, expanding blocks); if it doesn't get keyboard focus, a screenreader may not read it out to the user and the user may not realize that anything has changed. This is one area where it may be necessary to test with a real-world screenreader (eg. NVDA or JAWS) to ensure that it's actually usable. A simple approach is to only have UI appear in response to user request: eg user hits return on a menu item to make the menu appear, don't make it appear merely in response to it getting focus. Then when it does appear, set focus to the first item: this is both expected behavior for menus in most UIs, and changing the focus typically also causes the screenreader to read out the new item, which confirms to the user that something has happened. (Also, if using Javascript to add behavior to existing elements - eg. make a link behave like a button - use WAI-ARIA attributes such as role="button" to let the screenreader know what the intent is so it will read out that role to the user, and will say 'button' instead of 'link'.)
Is there anything major I'm missing?
I think you've got most of the key points already covered above; the WCAG checklist should fill in everything else. One major area that is worth mentioning is to use headers (H1, etc) appropriately. For screenreader users, navigating by header is a major way for navigating a page. Typically when navigating to a page that a user hasn't visited before, the user will hit a hot-key to get the screenreader to bring up a list of headings on that page as a way of 'skimming' to get an overview. Having good link text is also important; ideally links should be self-describing, so you don't just hear "click for more", "click for more" as you tab through a page.
For newer browsers, IE8, IE9, Firefox 3?, and Safari 5 (possibly 4), and newer screen readers WAI-ARIA is the way to go. Among other things it has landmark roles which if you have an ARIA reading screen reader, such as JAWS 12 and possibly JAWS 11 and 10, the screen reader can use to jump around. It can get a bit clunky if you want things to be backwards accessible but is the direction the web is going in. Their are many other advantages to ARIA but that's the one relevant to your question. On a related note VoiceOver for the Mac is supposed to be ARIA compliant as well.
I'm not disagreeing with the selected best answer, but I would spend more time learning about WCAG 2.0 than with the original WCAG specification. Both in the United States and internationally, the Web Content Accessibility Guideline 2.0 are quickly becoming the standard. In fact, the Access Board, the group tasked with defining the guidelines for Section 508, are refreshing the standards to be harmonized with WCAG 2.0.
You can find great information by starting here Web Content Accessibility Guidelines (WCAG) 2.0.
OK that's the worst title I could ever possibly think up. But I'm not too sure how to phrase it!
What I mean is, is it inefficient for the browser, search engine optimisation, or any other important factors, if programmatically my float:righted sidebar appears in the markup before the main content div, which is set to float:left?
To the user, the main content appears on the left, and the sidebar on the right. In the source code it appears like so:
<div id="sidebar">This is where my sidebar goes </div>
<div id="content">This is where my content goes </div>
Will this affect SEO or other factors in my page?
Yes, put your content first.
WordPress has a nice discussion about content structure and SEO. You want to put content as close to the beginning of the served HTML file as possible. Robots and screen readers will get to what they want earlier, and I'd guess that the browser would start rendering content according to its place in the served file as well. CSS makes positioning things out of order more or less trivial, so why not give the HTML content all the help it can get?
You really can't say... but I suppose it won't since bots like Google's web crawler follow links and not text... but it might effect the SEO of images, since those are indexed by "surrounding content".
However, it is really the Right Thing to do, since people on "restricted devices"(really old cell phones) and people using screen readers will see your content in the correct order.
Search engines nowadays are smart enough to distinguish between a navigation and the main content. You can help by adding meaningful class names or ids. I’ve never seen any real impact on ranking by the order of both sections.
Whatever you do: add a skip link for keyboard users to jump to the other section. It should be visible on :focus. And hide the navigation in your print stylesheet. :)