Kim’s Notes November 20, 2019

Posted by Kim Krause Berg cre8pc    Updated

Blind people navigate web pages by scanning headings inside screen readers to quickly understand content and layout.

For example, in JAWS, the “H” key jumps from one heading to the next, reading them in sequential order, no matter what level the heading is (h1, h2, h3, etc.). The “1” Key jumps through all of the level 1 headings (<h1>). The “2” key jumps through all of the level 2 headings (<h2>), and so on.

One of the main reasons to start with <h1> at the beginning of the main content is because screen reader users may use keyboard shortcuts to navigate directly to the first <h1>, allowing them to jump directly to the main content of the web page

Screen reader users often navigate from link to link by using the tab key (or shift + tab to go backwards through links). In this way, only the link is read, not the rest of the sentence, so undefined links like “click here” or “more” are not helpful.

Links should not be empty. Screen readers may end up reading the link destination or some other piece of information (such as an image file name, if the only thing in a link is an image without alt text) if there is no text in the link. 

Link text (and alternate text for images, when used as links) describes the destination or purpose of the link. The link text should make sense out of context of the words around it.

The proper way to distinguish links from the surrounding text is to use a combination of color and a secondary method that provides a visual cue to the user. The simplest and recommended visual cue is to add an underline to the link text. Add a background color and border when the mouse hovers over it.

If color is the only method being used, it must provide at least a 3:1 contrast ratio to the surrounding text during all states, link, hover and visited.

Users with motor disabilities need large touch targets. Some people experience hand tremors or imprecise hand movements. Other people cannot use their fingers, and may use other body parts, such as their knuckles, elbow, or toes.

Touch targets to consider:

  • Links
  • Menus
  • Submit Buttons
  • Checkboxes
  • Radio buttons
  • Text input fields
  • Select fields (comboboxes)
  • Custom widget controls like media player buttons

For native apps:

  • On standard resolution devices, set the width to at least 44px (according to Apple’s recommendations) or 48px (according to Google’s recommendations). On Android, it’s best to use the 48px size, due to Android’s layout grid .
  • On devices with double the pixel density (such as Apple Retina screens), set the width to at least 88px-96px in terms of true screen dimensions.

On web pages:

  • Set the width to at least 44px in the CSS (Android’s 48px layout grid is less relevant on the web, but it doesn’t hurt to make touch targets larger). Standard resolution devices will render it at 44px and double density devices will interpolate the value and render it at the equivalent of 44px, even though the actual value will be 88px.

Links within the text should contain enough characters that the touch target will be at least 9.6mm wide.

The more common way of increasing the target area is by adding legitimate label text, using the <label> tag. When the <label> tag is properly applied, all of the text in the label is clickable, so whether users click on the text or the button, the button will be selected.

Don’t use background images or watermarks to convey information, because there is no way to provide alt text for background images.