I have a page with tabbed navigation, and I need to make JAWS announce the tab statuses. For example:
________
Shop | Cart | Recent orders | Profile
--------------------------------------
When the user moves through the above tabs, JAWS should say something like
Shop tab; not selected
(Tab)
Cart; selected
(Tab)
Recent orders; not selected
(Tab)
Profile; not selected
Where I have "(Tab)" with the parens above, I mean that JAWS is saying the word "tab" because the Tab key was pressed to move between navigation tabs.
Currently, the words "not selected" and "selected" are not being spoken by JAWS, but the rest is. I'm using markup like
<a aria-selected="false" href="profile.html" id="profileTab">
Official JAWS documentation (reproduced online here) indicates that JAWS recognizes aria-selected but doesn't say what effect(s) the property has.
I can see the ARIA markup in my page source, but JAWS doesn't read it aloud, or do anything at all with it as far as I can tell. How can I get JAWS to say "selected" and "not selected" (or something similar)?
The authoring practice has a good section on the tab control. The demo site is using aria-selected like you are but it sounds fine with JAWS and Internet Explorer when I tested it just now, although the demo is setting aria-selected on a <button> instead of a link.
What browser were you using?
The latest version of JAWS?
Also, a tab control normally uses the arrow keys to navigate between the tabs (see aforementioned "authoring practice") rather than the tab key but that shouldn't affect whether aria-selected is read or not.
(As a side fun fact, you can turn off JAWS' announcement of "tab" every time you press the tab key. I use JAWS quite often and don't need it to tell me when I press the tab key. It's just audio clutter (for me). Ins+J > Utilities > Settings Center > Manage Key Labels > Tab > Toggle Mute)
Update
Sorry, had a brain lapse for a moment. I forgot to mention role="tab". That's what causing your problem. aria-selected is not valid on role="button" or role="link" but is valid on role="tab". See "Allowed ARIA roles, states and properties"
Change your code to
<a aria-selected="true" href="profile.html" id="profileTab" role="tab">
and it should work.
Related
<ul class="draggable-list" role="listbox">
-- list runs in for loop around 5 li elements (all draggable elements)
<li tabindex="0" role="option">
</li>
</ul>
All the drag drop li elements are working fine on mouse click drag and drop. But when I try to use keyboard enter for accessibility.. there is a on key press function which works fine in chrome but fails in IE and Safari.
I have tried role="listitem" but then on enter key press nothing happens on any of the browsers. is there any specific role i can use across browsers for list items which needs to be moved (basically need on key press event to fire, where I am deciding the location to move). I have tried role="application" this works across browser but there some other accessibility issue that come up. Everyone in the team suggested not to use application as a role for list elements (That doesn't seem correct to me as well but thts the only role which has worked on IE and safari safari for key press event)
list item
Note: list item doesn't have any keyboard interactions
Note that specifying a role does not give you any behavior. See "What adding a role does not do"
Adding an ARIA role will not make an element look or act differently for people not using assistive technology. It does not change the behaviours, states and properties of the host element but only the native role semantics.
In other words, changing the role only changes how the screen reader announces the element (the "semantics"). It doesn't cause the element to behave any differently.
Also note that the following in a previous answer is not quite accurate:
"A lot of screen-readers (depending on their user-settings) do not pass key-presses to the browser"
This is not true. Depending on the role of the element, the screen reader (with default settings) can switch between virtual/explorer/browse mode to application/forms mode, thus passing key presses to the browser (and thus to your element). For a list of roles that do this, see "5.1 Fundamental Keyboard Navigation Conventions". Even though that section talks about keyboard navigation and which roles require you to implement arrow key navigation, it essentially tells you which roles will allow key presses to pass through to your element.
So if you want key presses, use one of the roles listed in that section. As a last resort, use role="application".
From my experience, you can never be certain that role="application" will work consistently from time to time.
Roles: role="listitem" is supposed to be used when one or more options are to be selected. What you are describing sounds to me more like a regular list that the user can re-order, and not something like a <select>. If I'm correct, you could consider using a role="list" with role="listitem" for children - and as it happens, that comes for free when using a <ul>, so you can completely skip the role attributes here. You can also keep using the role="listitem", because some screen-readers will let users go item-by-item a little easier. Depends on your needs and preferences.
But addressing the real problem: A lot of screen-readers (depending on their user-settings) do not pass key-presses to the browser, so your onkeypress will not fire. At least not reliably. That's because the screen-reader relies heavily on keyboard shortcuts, and those might differ from user to user. You would not want to overwrite those.
However, when something can be tabbed to, the screen-reader will happily fire an onclick event when the user presses the Enter key.
When grabbing an item, you could consider adding aria-grabbed="true" and aria-dropeffect="move". Both are marked as "Deprecated", as a new method of conveying these are in the works, but I think they are still supported by some major screen-readers, and I have yet to find a proper alternative.
aria-grabbed: https://www.w3.org/TR/wai-aria-1.1/#aria-grabbed
aria-dropeffect: https://www.w3.org/TR/wai-aria-1.1/#aria-dropeffect
I'm working on a client project which acts as a resource and support system for vulnerable people. Accessibility compliance has been touted as the absolute highest priority for this site because of the expected users, so we're currently working to meet WCAG 2.0 Level AA as closely as possible.
Currently the code for the login/registration links in the header looks like this:
<div class="profile-summary">
<a class="profile-summary__link" href="/login">Login</a>
or
<a class="profile-summary__link" href="/register">sign up</a>
</div>
Another developer who is working on the user management system wants to change the login link to be a form containing a submit button. Something (hypothetically) like this:
<div class="profile-summary">
<form action="/login" method="get">
<button type="submit">Login</button>
</form>
or
<a class="profile-summary__link" href="/register">sign up</a>
</div>
This doesn't really sit well with me and it seems like something screenreaders and other assistive software will trip over (e.g. won't read the login option when summarising the page). To my knowledge some of these switch into a 'form mode' when they encounter a form, which would be jarring in this situation.
Are there any detrimental accessibility implications to using a form and button over a plain link in this context?
Thanks!
In this context, the link with href="#" is right out.
Adding a form can be more confusing than anything because it implies a different thing will happen between each of two otherwise similar controls. A form with no fields and only a button is even more confusing to many SR users. That may be a bigger problem than the links.
Remember that not all screen reader users are blind, so if these controls look the same but behave differently that is also an issue.
Without seeing what these two controls do, it is hard to offer specific advice about which element is the right choice.
Here is generally the way I approach this question...
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an <input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This had better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead. I tend to prefer <input type="submit"> as I find it runs into fewer conflicts (both mentally and stylistically) with developers.
Keyboard User Consideration
Think of keyboard users for a moment. A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I have a CodePen demo that shows this in action: http://s.codepen.io/aardrian/debug/PZQJyd
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
For reference: http://adrianroselli.com/2016/01/links-buttons-submits-and-divs-oh-hell.html
This question already has an answer here:
Why are buttons discouraged from navigation?
(1 answer)
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
From my understanding, buttons are used to carry out functions and links are used to navigate the user to a different page. But what is best practice in terms of opening and closing a modal?
<a id="testModal" href="#">Open Modal</a>
or
<button id="testModal">Open Modal</button>
<button>
Change the <a href="#"> to a <button> and put your event handler on it.
Some more context on which elements belongs where....
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an<input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This has better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead.
Keyboard Considerations
Think of keyboard users for a moment. A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
I think there are two possible cases.
Your content is only visually hidden in page or visible in page (can be read by screen readers) and can be hash linked, then an anchor tag might be appropriate (this case is not so common, eg: use case is if you are highlighting a paragraph or image on the page as a modal).
In almost all other cases, your modal is loaded on the same page and is in no way navigated using a url link (except through ajax for accessing data possibly, which doesn't count). Hence it is a custom functionality and a button is the appropriate choice.
Sort of by definition, a dialog is something that will pop up over the current window. You're not really leaving the window, it's just temporarily unavailable. Once you're done with the dialog, you typically go back to the window. So in that respect, you don't want to use a link because you're not going to another page. You're doing some action on the current page. Use a button.
When using a screen reader, I will often bring up the list of links (Ins+F7 in JAWS) to see what pages I can link to. I'll also bring up a list of buttons (Ctrl+Ins+B) to see what actions are available on the page. I would expect the action to bring up a modal dialog to be in my button list.
I manage several websites that use a featured article scroller on their homepages, which allows the user to click a forward or back arrow in order to see the next article headline and blurb while remaining on the same page.
I use WAVE's accessibility checker and any sites that have this particular plugin throw an error back because within the code there is an empty link, written as <a href="#">. Is there any way around this? I've defined a title attribute but the # is causing the empty link error to still come up.
Some places I've seen that this is perfectly acceptable and others claim this is a problem. What's the actual answer and potential workaround?
Change the <a href="#"> to a <button> and put your event handler on it.
Some more context on which elements belongs where....
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an<input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This has better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead.
Keyboard Considerations
Think of keyboard users for a moment. A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
Some source suggests that link would be an invalid hypertext reference, but in fact the problem would exist only in non javascript browsers which is out of the scope of WCAG 2. This is not your problem here as this is not an error that WAVE considers.
The problem here is the fact that you have an empty link content and that adding a title attribute does not satisfy WAVE algorithm.
If your only concern is to satisfy WAVE, just put some content in the link and use any CSS trick to hide this content.
I want to know, according to WCAG 2.0, in which cases the spacebar is used to interact within the page.
Is it use in the same cases as the enter key?
Should I provide the same function to the enter key and the spacebar?
Do not change the native behavior of controls. That can mess with users.
A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing.
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
I have a CodePen from another example that shows this: http://s.codepen.io/aardrian/debug/PZQJyd
If you are making something like a <div> clickable and trying to add keyboard interaction, then do not use a <div>. Use the right element for the purpose, which I briefly outline as:
Does the control take me to another page? Use an anchor (<a href>).
Does the control change something on the current page? Use <button>.
Does the control submit form fields? Use <input type=submit> or <button type=submit>.
As far as WCAG 2.0 it says specifically to use space bar only in 3 cases:
https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/
Checks the radio button with keyboard focus (this is a special case when using tab and no radio buttons have been marked as checked (https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224#kbd_general_ex).
It is recommended that the space bar be used for selection for Drag drop support (https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224#dragdrop)
Checkbox - Space bar toggles checkboxes, if the list items are checkable (https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224#listbox)
The WCAG only mentions a guideline:
"The TAB key moves keyboard focus to the widget, and other keys operate the features of the widget, typically cursor keys, Enter key and Spacebar. The actual keys are up to the developer, but best practices recommend using the same key bindings that are used to control similar widgets in common GUI operating systems like Microsoft Windows®, Apple OSX® and UNIX Desktops like GNOME and GTK."
Frankly its left to the user's interpretation, and based on what you are trying to implement, you would probably have to see the existing behaviour of similar components on popular tools/web sites/ browser behaviour and make a logical decision.