About CIA

 

Section 2. Focus

Accessibility Score Sheet Questions

2.1    Can all elements that a user needs to interact with receive keyboard focus and be reached using only the keyboard?

2.2    Is the current focus visually indicated on screen and programmatically exposed?

2.3    Does the focus move in a logical order or flow?

Rationale

The “focus” is the position on a screen where an action will take place. This can be indicated by the blinking cursor, a dotted outline, a highlight or other visual cue. Sighted keyboard users, those with ambulatory disabilities who can view the screen but can’t use a mouse to interact, have to be able to see the current focus point to orient and interact with content. Assistive technology (e.g., screen readers, screen magnifiers) also use the focus to determine content and possible actions. Every interactive element must be able to receive focus to ensure that navigation without a mouse will work. Visually and programmatically indicating the focus allows individuals with or without assistive technology to efficiently and accurately use the applications’ features.

Test Approach

1a. With JAWS turned OFF, test to see if elements can receive focus. You should already have a good idea from testing Section 1 but drill down into tabs, submenus, sets of icons, picklist items, and other specific components to make sure all parts of these are available to the keyboard.

Note: Read only text does not need to receive focus.

1b. Repeat step 1a with JAWS turned on

1c. Verify that JAWS can read the static text:

  • Use INSERT+Num Pad Plus to turn on the virtual cursor. This allows you to navigate around a page independent of the application cursor.
  • Use the arrow keys to move around the text on the page.
  • H should skip you to headings and T to tables. If it does not, hit INSERT+Space Bar and then try again.

2a. With JAWS turned OFF, test to ensure the focus is visible.

  • As you move around the interface, is there anywhere the focus goes where you can’t see it? This includes hidden skip links, buttons with the highlight turned off, panes without a highlight indicator, etc.

3a. With JAWS turned OFF, tab through pages and forms from the top to the bottom.

  • The cursor should generally move from top left to bottom right, without looping back to the top.
  • Test any conditional/dynamic for fields to make sure that they are added to the tab order correctly when they are displayed on the screen.

Note: Read only text does not need to receive focus.

3b. Repeat step 2a with JAWS turned ON.

Development Techniques

Both Client Applications and Web Browser Applications:

  • Consider placing the focus on an interface element when the application opens. In most situations, the focus should be placed on the interface element in the top, left of the screen.
  • If navigating away from a component requires more than unmodified arrow or tab keys or other standard exit methods, provide text instructions of the method for moving the focus away.
  • Reduce the number of keystrokes required to get to desired areas.

Web Pages/Applications:

  • Use tabindex=”0″ to allow elements that do not typically hold focus to receive keyboard focus. Use this to add an element to the tab order.
  • Use tabindex=”-1″ to allow elements that do not typically hold focus to receive programmatic focus. Use this to move the focus using a link or script. This is important for moving the focus to an error message or dialog box but it removes the element from the default tab order.
  • Ensure the CSS does not hide the focus indicator and consider enhancing it. The user should be able to identify where the focus is at any given time.

Client Applications:

  • The easiest way to provide object focus in Windows software is through the use of standard Windows controls. Windows notifies assistive technology when a window gets focus. It does this using Active Accessibility, window hooks, and window messages. When you use standard Windows controls or when the focus is on an entire window, no additional work is required to provide visual focus.
  • When standard Windows controls aren’t available use Microsoft Active Accessibility (MSAA). Applications can use MSAA to expose the location of the keyboard focus for custom controls and window content. To use this method, applications must:
    • Call NotifyWinEvent when the focus moves to an object that is not an entire window.
    • Handle the WM_GETOBJECT message when used to query the focus object.
    • OM objects representing screen elements must also support the accSelection property.
  • Support the IAccessible::get_accFocus property for custom user interface elements that are exposed with IAccessible interface.
  • For more information about MSAA, refer to the Microsoft Active Accessibility web page.
  • When MSAA isn’t available, the object focus can also be provided by positioning the system caret on the focus object. The system caret is the blinking vertical bar that the user sees when editing text. The caret can be placed anywhere on the screen, made any shape or size, and even made invisible. If the system caret is made invisible, it can be moved to indicate the focus location to assistive technology without disturbing what the user sees on the screen. This technique will expose the focus to assistive technology; but there must still be a visual indication of the focus object.

Posted: Jan 07, 2016 12:41 PM
Last Updated: Jan 07, 2016 12:41 PM