Is there any way in HTML to tell the browser not to allow tab indexing on particular elements?
On my page though there is a sideshow which is rendered with jQuery, when you tab through that, you get a lot of tab presses before the tab control moves to the next visible link on the page as all the things being tabbed through are hidden to the user visually.
You can use tabindex="-1".
Only do this if you are certain it does not remove functionality for keyboard users.
The W3C HTML5 specification supports negative tabindex values:
If the value is a negative integer
The user agent must set the element's tabindex focus flag, but should not allow the element to be reached using sequential focus navigation.
Watch out though that this is a HTML5 feature and might not work with old browsers.
To be W3C HTML 4.01 standard (from 1999) compliant, tabindex would need to be positive.
Sample usage below in pure HTML.
Focusable
<a tabindex="-1" href="#" onclick="return false">Not focusable</a>
Focusable
Don't forget that, even though tabindex is all lowercase in the specs and in the HTML, in Javascript/the DOM that property is called tabIndex.
Don't lose your mind trying to figure out why your programmatically altered tab indices calling element.tabindex = -1 isn't working. Use element.tabIndex = -1.
If these are elements naturally in the tab order like buttons and anchors, removing them from the tab order with tabindex="-1" is kind of an accessibility smell. If they're providing duplicate functionality removing them from the tab order is ok, and consider adding aria-hidden="true" to these elements so assistive technologies will ignore them.
If you are working in a browser that doesn't support tabindex="-1", you may be able to get away with just giving the things that need to be skipped a really high tab index. For example tabindex="500" basically moves the object's tab order to the end of the page.
I did this for a long data entry form with a button thrown in the middle of it. It's not a button people click very often so I didn't want them to accidentally tab to it and press enter. disabled wouldn't work because it's a button.
The way to do this is by adding tabindex="-1". By adding this to a specific element, it becomes unreachable by the keyboard navigation. There is a great article here that will help you further understand tabindex.
Just add the attribute disabled to the element (or use jQuery to do it for you). Disabled prevents the input from being focused or selected at all.
Related
What's the proper way to handle programmatic focus of web components?
Calling focus() on a web component should focus the appropriate element in the shadow DOM. This means overwriting the focus method.
This is not enough though, because the web browser is not aware that the component is interactive. One consequence it that clicking an anchor pointing to the element will not focus it as it would a native interactive html element like <button>. There may be other implications that I'm not aware of.
The only way I know to make an element interactive is to give it a tabindex value. But tabindex="0" will create an extra tab stop, while tabindex="-1" will remove all tab stops inside the component. So neither works. My next step is to set tabindex="0", then switch the value on focus() and blur(). It seems crazy to me that I have to do all this hacky work for such a basic requirement (making a web component properly interactive and accessible). Am I missing something? Is there a better solution?
I was missing something indeed. Web components have a specific API for this: delegatesFocus. MDN docs.
When set to true:
calling focus() on the host element brings the first focusable element within the shadow DOM into focus.
so does clicking inside the component on any non focusable element
the tab sequence is unchanged
:focus styles on the host are applied
It's part of the web components specs so no worries about support.
I'm doing accessibility work and testing tab focus.
Is there an easy way skip focus to a specific element on chrome or any other browser? For example, there is a button in the middle of the page. How can I quickly focus that element without tabbing through everything before it first?
Just use the focus method in JavaScript:
document.getElementById('myButton') .focus();
The focus method exists on all elements that are naturally focusable (like buttons, links, form elements), or that have been made focusable with the tabindex attribute.
For input elements, you can also use the autofocus attribute to tell the browser to focus it as soon as the page is loaded.
Many websites use "skip links" for the ability to bypass lengthy navigation menus and quickly access the certain areas of the page. This is useful for end-users as well as developers who are testing webpages.
The basic principle is that you'll have invisible links at the very beginning of the page that use anchor elements and IDs (just like any in-page link).
For example:
<body>
Skip to main content
...
<main id="maincontent">
<h1>Heading</h1>
<p>This is the first paragraph</p>
WebAIM has a very good tutorial on this.
http://webaim.org/techniques/skipnav/
When you visit their site, press the TAB key before doing anything else, and you'll see an example of how this works.
I would consider this method to be more reliable than using JavaScript, as HTML is more widely supported.
Open chrome developper tools
Inside the console, you can focus any element using the following:
document.querySelector(selector).focus();
The selector can be obtained right clicking the element inside the code of the developer tools and selecting copy / copy selector
This does not required the element to have an id attribute, but you still can use it.
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.