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.
Related
I've been trying to find an answer to this, but can't quite get a clear one. I'm using a MUI Select component in my app, and noticed that it the menu items are able to be navigated with up/down keys and selected with the enter key, but not able to go up/down with the tab key. Is this a best practice for accessibility, or is it not required? I also looked at this guideline, which seems like tabbing isn't required. Just want need some validation on this. Thank you!
If you mean the different options of a dropdown menu, no, they shouldn't be reachable with tab.
This is probably more a common convention or a recommandation than an absolute obligation, as far as I know.
It comes from native UI control/widget/component conventions on most operating systems that have been in use long time before the web.
The tab key is normally used to go from a control to the next.
But when you go through the different options of a dropdown menu, you stay on the same control.
So dropdown options don't have to, and even really shouldn't be reachable with the tab key.
The same answer applies on the different tabs of a tab control, or the items in a list of selectable items. Normally when navigating with tab, you should only reach the currently selected / active element. Another press on tab key moves to the next interactive control.
As mentioned before, the goal of TAB is typically to move from a specific input control.to another, not within it. Thus, the use of arrow keys and enter is fine. However as a screen reader user myself, I run across custom "selection" boxes that fail to work properly due to many reasons. even if keyboard navigation works as expected outside of a screen reader context. It isn't clear to me if you tried this under a screen reader.
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.
I like to display more info on certain keywords in a web page. I don't want to send the visitor to another page and I prefer to show the extra info on top of the current page.
The keywords are in an html list. It's basically a list of features and I want to offer more info about the features. So I have two ideas based on having 'More Info' or '?' hyperlinks.
The user hovers on the link and a popup window shows up with the info and goes away when they hover away.
They click on the link, a popup window with an 'X' shows up and they click on the X to close.
Which one offers a better friendlier user experience?
I like #1 because they don't have to click to open and click to close but the disadvantage is that windows might open inadvertently while they are mousing over the page.
Both are pretty annoying, but if I had to pick the lesser of two evils, I'd go with properly done mouseovers.
You can setup Javascript on the page to handle the accidental mouse over, and instead wait for a few seconds before displaying the popup window.
What would your users expect? Try not to break those expectations.
Maybe try a hallway usability study, grabbing a handful of users as they walk past the office, and just ask them to tell you what they would expect. :)
Asking Stack Overflow is a good idea too, but you won't get the advantage of context, which is very important with usability testing.
As a user myself, I find it annoying when I move a mouse and something pops up unexpectedly. Even with a javascript delay (which is better), I still think it's unexpected that something would pop up when I didn't explicitly click on it.
But, that might vary depending on the context of your application.
Personally, I'd go with the click option. There's a standard Way Things Work on the web which says that hovers are for information about the link itself and what action clicking on it will do ("See more comments", "Click for help", etc.), whereas clicking is what actually performs the action.
If you do decide to go with the hover option, make sure that you code it such that users can select the text in the popup. It's really annoying when you just want to copy some useful information somewhere and the GUI hides it before you can reach it.
Adding to what the others have said, I would also prefer the click option.
The problem I have with the hover option is that, and maybe this is just me, if the hoverable area is on the small side, I have a hard time keeping my mouse still enough to keep hovering. The cursor tends to move off the link in the middle of reading and my nice help text disappears.
People don't expect a pop-up on hover - I'd definitely go with the click.
Edit / addition: think about the website you visit every day - text and pictures are (generally) static, and hovering, at most, changes the colour or add underline to a link, or displays a small menu of clickable links.
When clicking on a link, you expect something to happen - a redirect to another page, a pop-up box with information, a form being submitted, etc.
I'm not saying this is the best way to do things, but it is the way 99% of the web works, and asking users to deal with pop-up boxes on hovers or the like is a good way to turn them away. I know I personally don't read any pages with double-underlined links; it's a good indication that an accidental break in scrolling to read the content might end up with my mouse over a link with an advertisement tied to it.
Having a little graphic beside clickable text, or otherwise denoting that clicking will lead to more information is a great way of providing contextual information without frustrating people. For most of the world, pop-ups without clicking still == advertisements or spyware.
Edit / clarification: I don't mean a pop-up in the new window sense, just a lightbox-style javascript pop-up. Don't take the user away from the page, and give them a very visible button to click to close the pop-up. I guess what I'm saying is that people don't expect something to happen without clicking, especially not if it's going to take up more space on the screen.
As a couple of additional precedents to consider, you might want to consider the functionality of the acronym and abbr HTML tags. Both allow you to provide extra information on a particular piece of text in the page, and both work on the "hover" principle.
Points to ponder:
If items are so dense that everywhere you move the mouse something pops up on hover then do NOT do hover!
Can you make hover show very brief info, and have click show more detail? This may be the best of both worlds if it works for you.
Can you have a dedicated box that displays info when you hover? This may be better than any pop-up. Opinions vary...
In the end it's what works for your app, from your users' point of view.