Is there a way to prevent an 'aria-live' element from being focused by a screen reader?
I'm developing a calendar and would like to notify user whenever the currently selected month is changed.
As others have said, keyboard focus does not have to move to the aria-live region. Any changes made to a live region will just be announced. The focus will not move.
However, if you are asking whether you can prevent the user from moving their screen reader focus to the element, no, you can't prevent that. As long as the element is part of the accessibility tree (a subset of the DOM), the user can navigate to that element and hear its contents.
The rules on whether a DOM element is part of the accessibility tree are spelled out pretty well in "5.1 General rules for exposing WAI-ARIA semantics". Specifically, in the "5.1.2 Including..." section, it says elements that have text will be included. I'm presuming your aria-live element has text because it's being announced as you change it. If you jump back up to the "5.1.1 Excluding..." section, you can prevent the element from being on the accessibility tree if you use aria-hidden="true", but if you do that, then the live changes won't be read.
If implemented correctly, aria-live region will never receive visual focus.
Make sure that the live region is present on the page initially, only then dynamically added/changed content will be announced. Live region of the page that gets announced whenever content changes but the focus doesn't shift to the live region.
Related
I'm trying to test the accessibility of a web page.
I'm using Apple Voice Over as screen reader on my MacBook and if I use voice over key short cuts, everything's working fine.
I can use voice over shortcuts (Ctrl + option + arrow-keys) to go through all elements of the page.
But if I turn the voice over off and try to navigate the web page using just the tab key, it doesn't work properly.
Tabbing just considers elements such as header, links and buttons but it ignores normal text.
Is this normal?
Is this acceptable?
It is totally normal, and it is actually the expected behaviour.
It is also acceptable because focus is meant to let user interact with some elements in the DOM. Only interactive elements are meant to be focused, the rest will just be ignored from the focus cycle.
The screen reader allows focusing pretty much any content on a page, as long as it is not set to be ignored by the screen reader (using aria-hidden="true" for example), and its behaviour can't really be compared to the tab cycle.
Using tab on a web page simply allows cycling through elements considered being interactive (i.e. focusable).
Text elements such as span, paragraphs, and even headers are not considered as focusable unless they are explicitly configured to be so. For example, specifying the tabindex attribute is one straightforward way to make an element focusable.
HTML 5.1 - User Interaction - Focus describes the focus mechanism in-depth and is worth reading.
Note that aria-hidden and tabindex can be used to make elements being focusable using keyboard but not being processed by a screen reader, or the opposite.
We are running a tool called Axe to check the validity and 508-compliance/accessibility of HTML pages.
This error comes up as a violation:
Elements should not have tabindex greater than zero
The app is structured with top links and a nav bar. If we don't put in a tabindex, the tabbing starts from those elements. The idea is to hit the form inputs directly when coming onto the page. Surely that makes sense and should be allowed (even for disabled users)? Then why is a legitimate use case getting flagged?
<input id="phone" name="phone" tabindex="5" placeholder="" class="input-block-level" type="text" value="222">
Having a tabindex greater than zero is allowed in HTML in spite of what AXE is saying.
However, the way that you're using tabindex is presenting information to sighted users that is essentially being made unavailable to non-sighted users because they can't tab to it.
A better way to approach this would be to use hidden "skip links".
The idea is simple enough: provide a link at the top of the page which jumps the user down to an anchor or target at the beginning of the main content.
https://webaim.org/techniques/skipnav/
For sighted users, it's nice to have the focus on the first actionable element, such as the search field on amazon.com (although they don't do that). But sighted users have the whole page to take in with a quick glance. They can see where the focus is (assuming you have a focus indicator, 2.4.7) relative to the rest of the page and will immediately know there are navigation elements before the focus location and more stuff to interact with after the focus location.
For low vision users that use a magnifier, their viewport will be shifted to include the element that has focus. Usually when a page loads, the focus goes to the first element in the DOM that can receive focus. That's typically a "home" logo in the upper left (for LTR languages). Because the viewport is in the upper left, the low vision user will know that they can drag their viewport to the right or down to explore more of the page. But if the initial focus is somewhere in the middle of the page, that can be disorienting. The user might not know where on the page they are. How far from the upper left has the viewport shifted? How far can they explore up or down, left or right?
For extremely low vision or visually-impaired or blind users, users that use screen readers, the disorientation is even more dramatic. Screen reading software has great navigation tools so it's easy to explore the various elements of the page, provided semantic html elements are being used such as <h2> or <table> or <ul>. You can navigate to headings using the 'H' key, tables via the 'T' key, and lists via the 'L' key. But again, screen reader users will expect the initial focus to be in the upper left. They can certainly orient themselves and figure out where they are on the page, but it does take some cognitive effort, similar to the screen magnifier user.
So how do you make a pleasant experience for all these types of users (among many other types of users too)?
As one answer notes, "skip links" are very handy. In accessibility terms, these are called "bypass blocks" (2.4.1). They allow the default focus to be in the upper left (or wherever the default focus goes) and when you tab, the focus moves to the "skip link", which is an in-page link that lets you jump to the main part of the page. This is great for keyboard-only users (which might be sighted or visually-impaired users), screen magnifier users, and screen reader users.
However, if you really want the focus to be on a particular element, if the element is an <input> or <button> element, you can use the autofocus attribute. For other natively focusable elements, such as an <a>, you can have javascript that runs on load to call focus() on the element.
It's not a WCAG violoation to have the initial focus somewhere on the page other than the first element, so you're ok putting it on your form, just do it in a way to reduce confusion for users that have limited sight or can't use a mouse.
For more information about tabindex, see "5.5 Keyboard Navigation Between Components (The Tab Sequence)". Note that for tabindex values greater than 0, it says:
"Authors are strongly advised NOT to use these values."
I manage a lot of ads on a website. I want to make the ads accessible, and I've been been researching this but there is little information out there currently about how to make ads accessible. While I look into this further, I'd like to make them at least invisible to screenreaders, so that they are skipped over and ignored.
The ads are usually in the following format:
<div class="ad">
<iframe>
<html><body><div>Various more child divs here</div></body></html>
</iframe>
</div>
Is it appropriate to use aria-hidden="true" on the parent div? I was reading that would apply to all child divs, which is great, but also that it is intended for items that are not visible to anyone, not just those using screenreaders. But the ad is visible -- I just don't want screenreaders to bother with it.
Ideally I would also like to make it so that the entire ad element is not part of the tab order and can be skipped over, but tab-index="-1" does not apply to child divs like aria-hidden="true" does, and as such I would need to apply it to all the child divs, which is difficult. I'm not sure if there is a way around this.
So this comes down to three questions:
Can I use aria-hidden=true on the parent div?
Is there a way to use tab-index=-1 to make sure the entire ad element gets skipped over when tabbing?
Is there anything else I should consider?
yes, aria-hidden=true will prevent screenreaders to read that
you can apply the same method I indicated in How can restrict the tab key press only within the modal popup when its open? to disable keyboard interaction (which is very simple with jQuery UI)
Accessibility concerns a lot of people where blind people using screenreaders are a small part of them. So your adds won't become magically accessible by removing them to screenreaders or from keyboard navigation.
If you put ads on your website, then you suppose people will want to click or navigate to them. How can someone who navigate with keyboard click on your ads if you remove it from the tabindex? How someone with low vision will be able to read the content of your ads using a screenreader if you remove it from your accessibility tree? It's for that exact reason that aria-hidden should be used to match the visible state of the element.
There are much more people with low vision or using keyboard navigation than full blind people using screenreaders.
I have been tasked with going through the a11y project checklist.
(http://a11yproject.com/checklist.html) for those who aren't sure what that is.
I noticed that on our website, (www.adn.com) when you tab through the website, it goes through our entire left-rail menu, before making it to the article content.
Is there some way to manipulate the order in which our site is "Tabbed through" for keyboard only users?
New to the industry, currently am a Junior Dev. Apologies if this is a simple question.
what you are looking for is tabindex
w3schools example
W3Schools
Google
Microsoft
Reference: w3schools.com/tags/att_global_tabindex.asp
The problem you're having isn't a tabindex issue, as the tabindex is correct for the menu's position in the DOM. (also changing tabindexes to values beyond 0 or -1 can really screw up the expected tab order for an interface).
What is going on here is that the menu has been visually hidden, by positioning it off screen, but it has not been adequately hidden from keyboard users/screen readers.
You'll need to update the CSS of your menu, so that when it is positioned off screen, the id="slider-menu-nav-list" is set to display: none. Then when the menu button is activated, the #slider-menu-nav-list should be set to display: block;
Looking through the source code some more, you'll also have to change your Menu button into an actual <button> element, as it's currently keyboard inaccessible as a <div><span> combo, so there is currently no way for a keyboard users to actually open the menu. (not all keyboard users are blind, and it can be frustrating to not be able to see where your current keyboard focus is located).
Hope this helps!
I have a page which I am supposed to make accessible without too many changes.
One combo box in the page is coded so that on clicking upon an input box, the contents of a div are copied into an iframe element in the same page, and that iframe is made visible below the input box.
I added aria-live to the container iframe, and Jaws would read the iframe that forms the drop down whenever it came up, but how do i link up the two such that Jaws focus can be shifted to the iframe whenever it is made visible and not just reading it out as a dynamic update?
I'm having a hard time understanding exactly how the UI is supposed to work based on your description. However, I can tell you that JAWS does not support aria-owns.
If you consult Freedom Scientific's documentation page, you'll find a Word document laying out JAWS' support for ARIA. It does not list aria-owns.