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.
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 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 know DIVs and P elements are not inherently focusable and can be made to be one by adding tabindex attribute. I am trying to make a Screen Reader friendly website and was wondering if it is necessary to have tabindex on each and every DIVs and P on my site so that the screen reading software like JAWS, NVDA and Chrome Vox can read its content.
Right now using Chrome Vox, it does not read a Paragraph content unless I have a "tabindex = 0" as an attribute. Am I testing it incorrectly? Do people who use screen reading software use some other way to read the page content then hitting tab to shift focus from element to element?
Only controls you want people to interact with (e.g. click or type into) should be focusable.
You should not need to make them focusable just to allow them to be read (and no screen reader I've ever tested (which doesn't include Vox) has required it).
Making them focusable would make it harder for people to use the site since they would have to tab through more elements to get the ones they want to interact with.
From the Chrome Vox documentation:
To navigate through the text on a screen, you can use the ChromeVox modifier keys. On a ChromeBook, the ChromeVox keys are Shift and Search, on Mac OS X the ChromeVox keys are Control and Command and on other platforms, such as Windows, the ChromeVox keys are Control and Alt. To move through a page, press the ChromeVox keys alongside the Up and Down arrow keys to navigate through the page.
you only have to put a tabindex="-1" on div tags which are the target of an anchor link
Go to anchor
[...]
<div id="targetanchor" tabindex="-1">
Using Chromevox, you have a list a shortcut to navigate through the page that you should be aware of, see here: http://www.chromevox.com/en/keyboard_shortcuts.html (ChromeVox + Down to navigate backward for instance)
I'm trying to inspect the shadow DOM for certain HTML5 controls, like the date picker for the input type="date" and the actual suggestion dropdown list for inputs bound to a datalist. Preferably in Chrome, but other browsers will do too.
I've found that by enabling the Shadow DOM setting in Chrome's inspector options allows me to inspect the shadow DOM for the actual input (which includes the ::-webkit-calendar-picker-indicator arrow to show the datepicker) but not the datepicker itself:
The same goes for the datalist. It appears as these controls are not part of the input, but I also can't find them anywhere else in the elements panel.
Is it possible to inspect such elements?
Small edit for clarification: I'm actually looking for which pseudo-classes apply to which controls. There's plenty of sites that list some of them, but I have yet to find a source that manages to list ::-webkit-calendar-picker-indicator for the datalist element, which does get applied. I'm looking for more of those sneaky bastards, and the best source for that of course is the horse's mouth.
Looks like the actual picker is loaded in an entirely different layer (basically a different window without the titlebar). So I guess the answer is: no, you can't.
I agree it would be great to be able to customize it. And similar popups too. Mozilla in XUL has display:popup which is used by context menus, flyout and similar things. Would be definitely great being able to use that in userland content too.
The calendar popup of Google Chrome is not in Shadow DOM.
It's in a separated page mapped to a popup window. See WebPagePopupImpl.cpp
And the popup content is written by HTML/JavaScript.
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.