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.
Related
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."
After a decade long hiatus I am dipping my toes into web development again. It still seems a very confusing heap of constantly changing standards to me, making it unclear which browsers support what and what the best practices are.
Currently, I am focusing on using the new semantic elements of HTML5. I found out the ASP.NET Core default Bootstrap template does not use the <nav> element for the navigation bar and was therefore looking into how to apply it properly.
The default navbar template in Bootstrap does recommend to use <nav>. However, I am confused as to what the purpose is behind the aria-expanded attribute applied to it. After learning about the benefits it offers to screen readers (indicating whether the navigation bar is collapsed or not, in this instance when the screen size is small, i.e., for smartphones), I am still confused as to whether it should be there at all. (And whether or not aria-controls should be applied, which it isn't in the default bootstrap template.)
Let me explain:
Some of these aria attributes seem to be describing visual behavior. Does it even make sense to describe something to the non-sighted which they can not see?
With the <nav> and <main> semantic elements applied correctly, don't the screen readers have all the necessary information at hand already to quickly skip the navigation bar (equivalent of hiding it for the sighted)?
Wouldn't a better alternative be to just hide the navigation toggle mechanism to the non-sighted altogether? Here my question then would be, how to go about this. Can a button be hidden using role="presentation" and/or aria-hidden="true"?
Using the example you cite at https://getbootstrap.com/examples/navbar/, it needs aria-expanded.
In the larger viewport, the "dropdown" menu hides all the sub-items. They are not only hidden visually, but hidden to screen readers as well. The aria-expanded helps give the user context whether or not there is more available, and also gives some clue about where the subsequent tab-stops may take the user.
In the narrower viewport, where the navigation becomes a hamburger, this still applies. Doubly so since it also applies to the hamburger itself.
This context is important since aria-controls support is poop (to quote Heydon).
There are cases where every item in a menu is available via tabbing, even if visually not there. In that case aria-expanded is not so important, but aria-controls would have more value.
Separately, that menu needs better :focus highlighting for sighted keyboard users, and DOM sequence for the menu versus logo in the narrow viewport (through that is my opinion).
Some of these aria attributes seem to be describing visual behavior. Does it even make sense to describe something to the non-sighted which they can not see?
That question should be the first to appear in any ARIA tutorial.
With the <nav> and <main> semantic elements applied correctly, don't the screen readers have all the necessary information at hand already to quickly skip the navigation bar (equivalent of hiding it for the sighted)?
And this one the second.
Edit: When I read those questions, I thought "that guy has already understood everything". ARIA tutorials rarely answer those questions because they are context dependent, but asking those questions must be the first step before using ARIA. Eg. image carousels are for blind people a very different user experience. Giving an aria-controls attribute to the "previous" button does not give more intelligence to a system based on visual effects. ARIA is not a miraculous panacea.
ARIA may be seen as a kind of magic potion for people wanting to make accessible something which is not accessible. In many cases it will be used ill-advisedly.
The aria-expanded can give a good user experience for screenreaders, informing whether or not an element can be opened to show more elements (for instance inside a dropdown menu).
You can't apply the aria-expanded directly on a nav element because it has to be set on an interactive element (like a button) to inform that this controls the visibility of another element inside the same container (which can be a nav).
The better alternative I can see is not hiding anything to also help people not using screenreaders. Instead of collapsing a navigation bar at small screen resolutions, it's perfectly possible to:
always show it
display a persistent menu icon to jump to the menu bar (or temporarily displaying it inside the viewport)
This has the benefit to enable the possibility to scroll to the menu bar (for people not understanding what that icon with three parallel lines may indicate) and let screenreaders users list all the internal links.
Of course, things are very different if you conceive a web application rather than a simple web site, and ARIA might be more useful in that context.
I'm hoping to improve the experience for people using screen readers on a site that has a few menu levels with a lot of links (that might feel endless to people hearing every item).
Is there a way of instructing the screen reader what to say? Other than using a link and the SR reading the text (which in this case wouldn't make much sense). I was thinking something like:
"Further filtering of events can be done in the following sub menu. If you do not wish to do so, please tab through the sub menu to the event listings."
I know this isn't ideal; - at the moment I'm trying to figure out how to allocate focus to an element without javascript/jquery so that the tabbing through isn't necessary - but for future reference (for example if an element needs further explanation that isn't a link with text) this would be good to know.
I already have a Skip Navigation link on the page, but that is for the main menu.
Multiple skip links can be used
You could create a hidden link before the menu that allows you to skip it, if that's what you mean. When a user tabs onto it, they would hear your instruction and by selecting it they could bypass the menu.
More information on the WebAIM site: http://webaim.org/techniques/skipnav/
Highlights:
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.
Probably the most accessible method for visually hiding skip links is
to hide them off screen, then cause them to be positioned on screen
when they receive keyboard focus.
Skip links or other in-page links can also be used to allow users to
jump to or jump over page content. For example, the Table of Contents
at the top of this page includes in-page links to facilitate
navigation to page areas. A "skip" link could also be used to allow
the user to quickly bypass confusing or potentially inaccessible
content, such as ASCII art, complex tables, etc.
The Open Ajax Alliance Accessibility Examples site might help: http://www.oaa-accessibility.org/example/25/
It is difficult to tell from your description whether this is applicable to your situation. If it is then the example site provides a great amount of implementation guidance for incorporating ARIA into your solution.
This works fine on my computer but im wondering if its a good idea in terms of accessibility, etc.
I have a page of product listings, and I want each listing to link to a product page. The listing is made up of an image and a few photographs of text.
I want the entire listing area to be a link, including white space. So rather than make the images and text links individually, ive put the entire div in a link.
As I said, this is working fine on my computer, but is a good idea for a production site?
Thanks
If it's like a grid or something, and you give a visual cue when the user moves the mouse over the row (background color changing etc) along with the cursor becoming a hand, it should be fine if you use the whitespace as part of your link.
If you want me in your website's audience, I would prefer if you wouldn't. When switching between windows, clicking in the window area is the quickest way to switch focus between windows. If like 80% of your window is really a link, I would find that annoying. I think I am not the only one.
The way it sounds there is also plenty of area which you can make behave like a link, such as the image, and the text in the grid. If that would be clickable, that would be big enough a target to hit.
Also imagine your app being used on a touch screen. These sometimes imsinterpret drag (scroll/zoom) and tick gestures. Which is annoying if everything responds to clicks.
Look at the right-side video links on YouTube. These are block-layout spans wrapped in a tags. (Not that just because Google does it means it's a good idea, but...)
If the area has a :hover color (as these do), then it should be clear enough to the user that this is an action item.
Syntactically it's invalid, you cannot put block elements (div, p, table) inside of inline elements (span, a, strong, em).
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.