Just announced: Level Access and eSSENTIAL Accessibility agree to merge! Read more.
Webinar Icon

Last week’s presentation in our Accessibility Basics Webinar Series covered best practices for keyboard accessibility. Training Director Eric Lyons presented the webinar and has provided answers to the questions we received during Q&A – both those that were answered during the webinar and those we weren’t able to get to during the allotted time.

The webinar slides, transcript, and recorded presentation can be accessed at https://www.levelaccess.com/resources/overview/.

How many elements can have a tabindex=0?

//EL: There is no limit to the number. Just keep in mind that there is no need to put a tab index on elements that already receive keyboard focus. These would be anchors, input fields, buttons

If the design of a page has the “save” button at the top, above the form fields, should the focus order match the visual order or should the save button be last in the focus order so users can get to it after entering the data?

//EL: That is a business decision. If it makes more sense to have the Save button at the top of the form, then the focus order should match. Otherwise, someone tabbing through might think they cannot interact with the button should the tab key skip over it

If I made a button with button code, would it get focus without adding the tabindex attribute? If so, is that better than using a div for a button?

//EL: <button> by default receives keyboard focus. Because it is native, it makes more sense to use a button rather than try to make sure a custom <div> works

What is a tabindex?

//EL: It allows you to place focus on an element that by default cannot receive it. Examples include <div>, <span> and <td>/<th>

What is a “div'”?

//EL: A container HTML element

Are there event handlers that handle both keyboard and mouse?

//EL: I don’t know of any except for the onClick, but that only fucntions for both if placed in an anchor

Is onkeydown for both mouse and keyboard?

//EL: No, just keyboard.

There are many possible styles that could be used to indicate focus; solid or dotted borders, backgrounds, underlining text, etc.  Are there standard recommendations for which visual styles are preferred?

//EL: Not really, but making sure if you do use custom styles, that they meet the contrast requirements we discussed during the Color section

Do contrast requirements apply to the focus indicator?  Ie if a focus box has been styled to appear in dark blue, but the button is dark gray, is that a contrast issue?

//EL: Yes. You should ensure that the focus indicator respects contrast settings

Some browser’s dotted rectangles for maintaining focus are very hard to see. Are there contrast standards for this?

//EL: The default focus indicator is generally viewed as suitable, since it is a default indicator. But to enhance the user experience, many developers create custom indicators, and use the WCAG contrast ratios as a guideline.

What is the value in using positive tabindex (why would we ever want to do that rather than do tabindex=0)?

//EL: If there is a business value in having a user interact with certain elements first, then using positive TabIndex is suitable. For example, having someone tab to a login widget first, log in, then continue, as this might provide a better user experience.

You mentioned that some UI designers purposely disable the outline because they feel it detracts from their design, but is it OK to render focus only if the user is reaching controls via the keyboard (e.g. no focus shown if you click on an object).

//EL: Well keep in mind that all controls that can be clicked with the mouse must be able to be controlled with the keyboard. So to remove focus indication for elements that can only be used with the mouse presents an even bigger issue of the keyboard not being able to interact with those controls.

If the tab panel is used, what command is used for a screen reader to read the content belonging to active tab?

//EL: I’m not sure what the actual commands are to read the content, but if a user keys into a tab group, they use the arrow keys to move from tab to tab, and activate with the enter key, exposing the new content.

Do you suggest adding onclick, onkeypress, etc… events right on the elements?

//EL: Not needed. I know that is what we show in the examples, but that’s more for effect. You should have these functions in your scripts.

Should temporarily disabled controls be skipped in the tab sequence?

//EL: Yes.

If there is a close button at the top of a dialog box, should focus be shown at the beginning or at the end of dialog content? What is preferred in terms of accessibility?

//EL: You should set focus to the close button first, or to the div containing the dialog, with the first tab stop being on the close button. Either or, but you want it to go to the top.

When it comes to visual focus may I stylize the focus from anything other than a dotted line?

//EL: Yes. You could use a solid line. Again though, pick colors that provide good contrast.

For pages with a large number of input elements, is there a way to navigate the page by larger sections so the user does not have to tab past every element in order to get to one in the middle of the page?

//EL: There are multiple ways a user can navigate through a page. Using A regions, a user can move from region to region. Example, a navigation region of main region. You can also split your forms up via headings, and this provides another way for a user to navigate.

Where would I look for a list of all these native elements which already have tab index and keyboard event handlers?

//EL: You could take a look at the w3.org site. They have some useful information. Anchors, input fields and buttons receive focus by default. OnClick on an anchor with a valid href fires from the keyboard. But other combinations are available online.

Do you have a list of commands for keyboard?

//EL: http://www.freedomscientific.com/ provides lists of common keyboard commands used by screen reader users.

Will most screen readers read the “title” attribute on input tags on mouseovers?

//EL: If there is no other information present, a screen reader may read the title attribute when they place focus on an input field, regardless of the mouseover. But screen readers don’t read the title by default. We’ll talk more about that during the Forms webinar later.

If a span tag is used to display a message on the screen, will tabindex=”0″ give it focus?

//EL: If a span tag houses a message that after an action is fired, you will need to give it a tabindex=“-1” to allow it to receive focus. We’ll talk more about that during the Dialog webinar in a few weeks.