I have a div element (which has another div inside it) which currently has role="button".
This element is under the body, and this creates a violation when
auditing with certain accessibility assessment tools (DAP specifically).
The reason for the violation: "All content must reside within a WAI-ARIA landmark or labelled region role"
When using roles other than "button" it becomes unclickable when using the JAWS screen-reader.
I've tried giving a role="complementary" the main div, and role="button" to its child div - this made the entire element unclickable using the keyboard.
Any suggestion will be most appreciated..
Thanks!
The div where you are using the role as complimentary should have a tabindex of -1. The button you want to focus to should have a tabindex of 0/1. This will make sure that the accessibility readers will focus on this component and when they do, it will select the button.
Here is a link that may help:
https://www.w3.org/TR/wai-aria-practices/
Hope this helps!
Related
Does using absolute positioning on a website negatively affect voice activation software?
Context:
I'm working for a company who have had their website's accessibility assessed. One of the comments was:
The tick box shown here is not being picked up by Dragon.
This means that a voice activation user would need to use keyboard commands in order to tab onto them.
Ensure that voice activation users are able to access the checkboxes by implementing the following in the CSS:
.checkbox__input {
/* position: absolute; */
cursor: pointer;
/* left: 0; */
/* top: 0; */
width: 38px;
height: 38px;
margin: 0;
opacity: 0;
}
The commended-out properties are their suggestions on what we should remove from our CSS.
I am aware that using position: absolute takes content out of the normal flow of the page. However, we are wrapping each checkbox in a container that is relatively positioned.
Their comment is suggesting to me that there is an issue around using voice commands on content that is absolutely positioned, but I can't seem to find anything online about if there actually are any issues.
For those curious, we do not want to implement their proposed changes because it changes our page design negatively.
The OP is asking about speech recognition, such as Dragon, and not screen readers.
Positioning has nothing to do with speech recognition and the recommended CSS seems silly to me. Two obvious things can affect speech recognition:
the role of the element
the displayed label of an element compared to the underlying accessible name
For the role, if you had a <div> that was styled to look like a checkbox, but the <div> did not have a role="checkbox", then a speech recognition user would not be able to say "click checkbox".
For the label, if the visual label of the checkbox does not match the accessible name of the checkbox (which should be a rarity), then a speech recognition user might not be able to (directly) select the checkbox. For example:
<input type="checkbox" id="mycheck">
<label for="mycheck">do you like dogs?</label>
A speech recognition user will be able to say "click dogs" or "click like" or "click <any word that is part of the visible label>".
However, if you had something like:
<input type="checkbox" id="mycheck" aria-label="are you a puppy lover?">do you like dogs?
then visually, both cases would look the same but the visible label, "do you like dogs?" does not match the accessible name, "are you a puppy lover?", and a speech recognition user would not be able to say "click dogs" or "click like" because neither of those words are in the accessible name. They'd have to say "click puppy" or "click lover", which would not be obvious.
Now, regarding positioning, if you had an object that was "on top" of the checkbox and that object on top received click events, then maybe positioning might affect Dragon, but I'm not sure. With a mouse user, if they try to click the checkbox but something (whether visually apparent or not) is on top, that top object will receive the event. If the speech recognition user says "click <checkbox name>" and an object is on top of it, I don't know if the checkbox will receive the event. It seems like the checkbox would get selected because you used the name of the checkbox and didn't rely on the DOM order for an object to receive the event.
Screen readers typically follow the order of the HTML (including any HTML generated by scripts) when reading a document. When CSS is used to position content, the content that appears on the screen can appear be in a different order from what appears in the code.
From Penn State's Accessibility Office:
The position attribute is used to change the visual position of an element regardless of where it is in the code. For example any item with position:absolute and position set to top:0px and left:0px will be displayed first visually, even if the div is the final text in the HTML code. Alternatively, an item may be listed first in the code, but actually be positioned to the bottom right side of the page visually.
This can be a problem for screen reader accessibility because content can be read out of context and therefore be confusing.
http://accessibility.psu.edu/css/readorderhtml/#fxd
Relative positiong presents the same problem.
The only way to overcome this issue is to allow items to render on screen in the order that they appear in the HTML. This may mean making adjustments to your HTML code, scripts, templates, etc.
This doesn't mean that you can't use CSS to position and align things -- you certainly can. It just means that you shouldn't use CSS to re-arrange the order of things.
We have a set of moving clouds (implemented using divs) in a home page of a web project. IE 10 focus on these elements with tabs even though they are not focus enabled elements (no tab index).
Without a code sample, I'd purely be guessing.
Something to try is to set the div's tabindex to -1.
<div class="pretty-cloud" tabindex="-1" />
The other option is that there is an element inside these divs which is tab focussable. Try the trick above to make it so they aren't, if you still want to use that type of element.
I have a dialog box in my application which displays a list of cards. I made a jsbin simplified version of it
http://jsbin.com/qopocej/edit?html,output
If I click on the blue outline on any of the cards a nice dialog box pops up with a short menu item in it. Particularly click on the blue outline below 'Joe' and see how the dialog box covers the current card and those surrounding it.
I need to refactor the code so that this current element in each card action is a new custom element, which brings with it all the functionality of displaying the menu dialog box. In the real application this does some ajax calls to the serve to update information.
The problem I have is that the very fact of refactoring has destroyed the way the dialog box displays. This is shown is this jsbin
http://jsbin.com/vecoxuh/edit?html,output
Click on the red box under 'Joe' and see how the dialog box is above the current card, but slips under the other cards nearby
I assume it is something to do with "stacking context", since the explicit styles that has added a z-index to each of the two dialog boxes should imply it still works, but it doesn't
The .item with an active dialog needs to be set a z-index that's higher than its siblings. The child dropdown menu's z-index is relative to that of its parents, no matter what it's explicitly set to. So if the furthermost parent does not have a z-index that enables it to overlap the other cards, none of its children will be able to do the same.
I'm trying to place a down-arrow in my navigation menu, if there is a li within an li.
Hover over the Shop link to see where I'm having difficulty - http://codepen.io/anon/pen/ABucF
The arrow (or V for my demonstration purposes) should be just after the Shop tab, Check Out and My Account, not inside it.
How would I be able to achieve this in the CSS?
Thank you.
You're trying to look at an element to check for a specific condition and style its parent based on that.
CSS can't yet be used to style parent elements unfortunately.
Your best bet is to simply add a class onto each element you want styled and do it that way or to physically place an icon/img in each anchor tag that requires it.
Alternatively use JavaScript to make it happen.
give a class to the parent who has sub child in it i.e Shop
.parent:after{
content:"V";
//or
background:url(image.png) no-repeat position;
}
updated pen
JSFiddle (The *:focus rule is to illustrate which element is marked as having focus.)
What I'm wondering is why, when I click a menu item, it gets the focus... but clicking a menu item does not give it focus.
What's wrong with the CSS to make it behave this way?
focus is generally only for elements that can receive keyboard or other input, so by this heuristic lis don't qualify. This question has more about it..
In the specs, CSS doesn't explicitly define what elements can be in those states, so it's hard to come up with a set rule for what can and can't be set to focus.
What might work for your purposes is active, which you can view here.
There is a small trick - if you want an item which not have focus anabled by default you should make it tabbable by seting its tabindex="N" - N is a number. As simple as that. if you add tabindex to your clickable items they will get focus when you click. If a tag can be tabbed it have to be able to get focus. Adding tabindex attribute to all nodes of the menu is very simple if you have jQuery loaded:
$(function() {
$('#navbar *').attr('tabindex', '1');
});
end everithing comes in place. You can do it using pure JavaScript of course.