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.
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.
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.
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.
In my application, I render one or more iframe elements in the main page, each of which displays the summary of a data record. What I want to do is to allow the user to click somewhere in that display and pop up a p:dialog box that displays more data and input controls.
The problem is that the dialog only shows in the confines of the iframe. Is there a way to allow it to plot outside the border of the iframe rectangle or the browser window?
If not, is there some other JSF component that can do this?
I already posted this question on the primefaces forum, but I think they are too busy to respond.
No, this is not possible. All modern browsers prevent any visual elements from leaving the confines of the browser's rendering area. This is to prevent a web page spoofing bona-fide operating system windows, among other things. An iframe is also considered a separate "browser" for the purposes of this limitation.
Additionally, this is a pure html/css/browser limitation. The tools (jsf/asp.net/php/etc) used do not come into it.
Some more info (from IE6/sp2+):
About Window Restrictions
http://msdn.microsoft.com/en-us/library/ms537638(v=vs.85).aspx
These constraints are equally applicable to all modern browsers (not that IE6 is modern, but that's kind of my point.)
I am currently attempting to make my application be more user friendly to those with difficulty seeing. As one would expect, I am using JAWS to test my application. Most of the issues I have run in were relatively easy to fix, except I am stumped on one.
In my application, I have advertisements injected via an iframe and I want JAWS to ignore them, but I still want them to display (display:none is out of the question). Is there any way to have JAWS completely ignore an element and all of its children?
I saw a few posts leading towards speak:none, but that does not work. It does seems to ignore the parent div, but it will instead reads the content of the iframe child.
Any tips would be greatly appreciated.
Thank you.
Good for you for testing your web application for accessibility.
JAWS already has the feature built-in to ignore ads by temporarily or permanently ignoring inline iframes.
Testing that your site works nicely with that feature toggled should represent the typical experience for a JAWS user.
Banner Ads
If you want JAWS to temporarily ignore banner ads on a page, do the following:
Press INSERT+V.
Press I until you select "Inline Frames Show - On."
Press the SPACEBAR to choose "Inline Frames Show - Off."
Press ENTER.
To have JAWS permanently ignore all inline frames, including banner ads that you might encounter:
In Internet Explorer, press INSERT+F2.
Select Settings Center, and press ENTER.
Focus is in the Search edit box. Type in "ignore inline" without the quotes.
Press DOWN ARROW to move to Ignore Inline Frames in the filtered results of the tree view in Settings Center.
Press SPACEBAR to check or uncheck the check box.
Press TAB to move to the OK button and activate it with the SPACEBAR. The changes are made and saved. Settings Center closes.
http://www.freedomscientific.com/Training/Surfs-up/difficult_pages.htm
The other points mentioned on the above link will give you a good idea of additional bad practices to avoid.
Give the ARIA attribute aria-hidden="true" to the outer div of the iframe. This should ideally hide the the content from JAWS.
Give the aria attribute role="presentation" to any element you want ignored. Jaws will not read them.