Webinar Icon

Accessibility Basics Series #8 Q&A – Focus Control

  • 0
  •  0

Last week’s presentation in our Accessibility Basics Webinar Series covered best practices for Focus Control. Accessibility Training Specialist Erica Zelmanowicz 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://dev-level-access.pantheonsite.io/resources/overview/.

Focus Control Q&A

You mentioned earlier to give a Dialog heading focus when it opens, but the heading will be a non-actionable item. Is it ok in this case?

//EZ: When a dialog is displayed, focus should move to the dialog, however, the dialog as a whole (or the non-actionable item) is not actually placed in the tab order, meaning that when the user presses the tab key, they do not actually move focus to the heading of the dialog. Focus should only move to the heading of the dialog when the dialog appears.  Use tabindex=”-1” and the javascript .focus() method to move focus.

Isn’t the title attribute problematic for keyboard only users as well as mobile and tablet users?

//EZ: In some cases, the title will not be announced by screen reader users. The title attribute typically should be used to provide advisory information to the user. If you include the title attribute, you could also add a <span> with accessible text off screen that identifies the purpose of the link.

Question combining passed webinar topics of color, forms, and related to this webinar on Focus Control…in a form, we have different states to indicate user interaction. The default labels are color contrast compliant. Once as user has entered info into the field and moved off focus on that input field, is it still compliant if the label color were to change to a non compliant contrast (light gray)? The assumption is the user has already interacted, entered their information, is aware of the field itself and moved off focus. Only color has changed and not anything programatically.

//EZ: The color contrast must still meet the color contrast requirements in this case. If a low vision user wants to scan through the form to ensure they have answered all the questions correctly, the sufficient color contrast for the labels will be important for those users to determine if they are missing any information.

Is there a more stylish way that can be used to focus on a link that would meet the standards? Maybe a background or double underline? The outline is not very attractive. Can we find a balance between visual design and accessibility?

//EZ: You can use whatever style you would like on the focus outline, however, ensuring that the outline has good contrast is very important. Remember that the best practice is to provide a highly visible, visual indication of keyboard focus.

What if it is not a new window that opens but rather something like a pop-up tool tip?

//EZ: If you are displaying a popup or dialog when the user activates a control for example, you will also need to identify the presence of that dialog. You can add off-screen text to that link that reads “opens a dialog” to let the user know what action will occur when they trigger the control.

Isn’t using the title attribute problematic? I’ve always heard not to rely on it as many who use AT have it turned off.

//EZ: See Previous Response

Can you explain again how you are getting the visual box around your focus? I am on the website right now, with a mouse, and I don’t see them.

//EZ: When you press the tab key to move from link to link, you should be able to visibly see the focus rectangle around those links. If you are not seeing the outline when pressing the tab key, most likely the developer is using outline:none to remove the default visual focus rectangle.

Where should programmatic focus go in an application, going from one page to the next page with a Next button? If the focus were to go to the first actionable item on the next page, then screen reader users do not hear the opening paragraph(s) of text. When we moved the programmatic focus to the first heading on the next page, the client was concerned seeing such a visible focus indicator on a non-actionable item.

//EZ: This is a complex question that probably requires a bit more detail in terms of the specific application, but in my opinion (and based on my colleagues’ opinions and experiences), it is best to not set focus at all and to let the screen reader start at the top of the page. You can provide a method for users to skip to the main content of the page and screen reader users will know how to navigate to the specific button or control on the page when they need to move to the next page.  In cases where you have a search field where the purpose of the page is to search (like Google), you could set focus to the search field but this is not a requirement.

For links that open in a new tab/window, would an aria label be sufficient, or does there need to be visual indication as well (e.g. “new window”, pop-out icon)?

//EZ: See Previous Response

I have some social media icons on my page with onclick elements. If i add the onfocus attribute will my content be accessible? Or how i can make them accessible which are onclick elements?

//EZ: For any simulated controls where you are using a div with an onclick event, ensure that you are also using a non-device dependent event handler such as onkeypress. This will ensure that the user can activate the control with the keyboard.  Also, since div elements do not naturally receive keyboard focus, ensure that tabindex=”0” is sent on the element so that the user can press the tab key to move focus to it.  The best implementation is to use standard actionable elements that naturally receive keyboard focus such as anchors or buttons.

No Comments

    Leave A Comment