Skip to Search Skip to Content
More Information
  Contact Us  |  Site Index  |  Calendar
Oklahoma ABLE Tech
Visit OK.gov
  • Home
  • Services
    • Device Demo and Loan
    • Device Bank Loan
    • IT Accessibility
    • Fire Safety
    • Vending iPads
    • SoonerStart Collaboration
    • Accessible Instructional Materials
    • Oklahoma AgrAbility
    • Training
  • Oklahoma Equipment Exchange
  • DME Reuse
    • DME Inventory
      • SoonerCare Available Equipment
      • Publicly Available DME
    • DME Forms
    • DME FAQ's
  • Resources
    • Education
    • General Resources
    • Fact Sheets on Employment
    • Publications
    • Webinars
    • Early Intervention
    • About Us
    • Advisory Council
    • Contact Us
  • Special Education Resolution Center
    • Training
      • Effective_Collaboration
Oklahoma ABLE Tech / IT Accessibility / webtips

Oklahoma ABLE Tech Weekly Web Accessibility Tips 

wheelchair symbol key on keyboardWeekly Web Accessibility Tips are brought to you by Oklahoma ABLE Tech, WebAIM, and ATAP.  For more information about Oklahoma’s electronic and   information technology accessibility law and standards, please visit www.accessibility.ok.gov or call Oklahoma ABLE Tech at 1.800.257.1705. 

Each week Oklahoma ABLE Tech sends an e-newsletter containing Accessibility Web Tips designed to aide web managers in making the web a more accessible place. Weekly Web Accessibility Tips are archived and brought to you by Oklahoma ABLE Tech, WebAIM, and ATAP. If you would be interested in receiving the web tips please follow the link and submit the form: Web Tips Form.

Small Text

WCAG 2.0 does not provide requirements for text sizes. It is easy to overlook the impact that small text has on web site users, particularly those with low vision. Because text sizes vary based on the font face in use, the user's display, viewing distance, etc., use common sense in determining if text is likely small enough to cause issues. As a very general rule, text that is sized smaller than 10 pixels in height tends to cause readability issues for many users.

Avoid Using Too Many Links

A page with a large number of links can be very difficult for some users to navigate. Screen reader users, as well as some users with cognitive disabilities, may be overwhelmed by the number of links that are presented. Users with motor disabilities may find navigation tedious (imagine navigating through 100 links using a stick in your mouth), and the effectiveness of speech recognition software can be diminished (e.g., Dragon NaturallySpeaking has difficulty with pages that have more than 200 links).

Use Unique Link Text

Screen reader users and users of speech recognition software rely on link text to navigate through links on a webpage. Not only does link text need to be descriptive, it needs to be unique to the page. Navigation by links can become difficult if multiple links use the same text, or even begin with the same text. Generic text at the beginning of a link should generally be removed wherever it occurs (e.g., "click here for...", "visit...", "read more about...", "more information on...","go to...", etc. ), and links with the same text should be avoided (e.g., "Visit this site's homepage" could be changed to "NASA homepage").

Consider Multiple Disabilities

An area of web accessibility that is often neglected is considering the needs of users with multiple disabilities. While addressing the needs of users with distinct disabilities is relatively straightforward, meeting the needs of users with multiple disabilities introduces some complex considerations. Here are a few of many combinations to consider:

  • Users that are deaf and blind can perceive content through a refreshable braille display (typically connected to screen reader software). Content that is accessible to users that are blind and also accessible to users that are deaf, generally meets the needs of deaf-blind users. However, a few unique considerations are needed, particularly for media where only a transcript can provide sufficient accessibility. Additionally, a graphical CAPTCHA that provides an audio alternative cannot be made accessible to a user that is both deaf and blind.
  • A flashing banner advertisement (while certainly distracting) likely falls below the minimal size requirement that may cause a photo-epileptic seizure. But what about a user with photosensitive epilepsy and low vision that may magnify the flashing image so that it exceeds the size threshold?
  • Screen readers are complex software. Modern web applications often introduce complex keyboard interactions. This combination may introduce difficulties for a user that is blind and also has a cognitive or learning disability.

Screen Magnification

Low vision (vision that cannot be corrected to normal levels with glasses or contact lenses) can be caused by a variety of conditions including glaucoma, cataracts, and macular degeneration. Many users with low vision use screen magnification software to enlarge content on the screen. Screen magnification software may also be used to change the default color scheme and read content out loud. Keep the following principles in mind while designing for users with low vision.

• Use true text instead of text within a graphic text when possible.
• A proper heading structure can make it easier to navigate large blocks of text.
• A flexible page layout that allows for multiple page widths will reduce the need for horizontal scrolling.
• Succinct text, especially link text, can reduce the need for scrolling.

Motor Disabilities

Some users have motor disabilities that make it difficult or impossible to use a standard keyboard or mouse. Although these users may rely on any number of assistive technologies to interact with a computer, the computer will generally treat these devices as either a mouse or a keyboard. All of these devices interface with a computer in one or more of the following ways:

• Uses a mouse or pointing device. This includes trackballs, eye tracking, or other devices that behave like a mouse.
• Uses a keyboard, including adaptive keyboards.
• Uses speech recognition.

Ensure that you web site interfaces are accessible to these technologies.

Carousels and Accessibility Issues

Many websites, particularly home pages, contain carousels - a section of the page that automatically rotates through a series of images or content. Carousels can often introduce accessibility issues, especially for screen reader users. In order to make a carousel accessible, several things must occur:

• It must be accessible using only a keyboard.
• Users must be able to pause and resume the carousel.
• The information contained in the carousel must be readable by screen readers.
• It needs to be designed so that the user will not encounter problems if it updates when the user is reading or has keyboard focus on it.

The accessibility of a carousel should always be tested in a screen reader.

Are "Skip" Links Still Necessary?

"Skip to main content" or "skip navigation" links provide a mechanism for keyboard users to jump over repetitive navigation directly to the main content of a page. Headings, ARIA landmarks, HTML5 structural elements (particularly <main>), etc., also provide elements which users can navigate to get to main content, but navigation by these elements is not yet supported in standard browsers for sighted keyboard-only users who are not using screen readers. Because of this, "skip" links still provide very useful functionality for sighted keyboard users. "Skip" links can, however, be hidden visually until they receive keyboard focus.

CSS3 Transitions and Animation

CSS3 allows new forms of animation and transitions. These transitions are purely visual, so they do not interrupt screen reader or keyboard reading or functionality. However, the animations can cause distraction, confusion, or disorientation, particularly for users with some cognitive or learning disabilities. These transitions are also sometimes used to convey content or meaning (such as through animating images or by providing visual associations between content). Because accessible content cannot generally be presented using CSS, alternative content or versions would likely be necessary.

HTML5 Main Element

HTML5 currently allows the newly defined <main> element to be used to identify the main content area of a web page. This element should be present on nearly all HTML5 pages. It can greatly facilitate navigation directly to the content area of pages by keyboard and screen reader users. For pages that are not yet HTML5, the ARIA role="main" can be added to the main content area to provide similar functionality.

HTML5 and Captioning

A primary issue with captioning has always been the wide variety of caption data formats. Each media player supports a different format for captioning. This has made authoring and converting of caption data difficult. In HTML5, audio and video natively support captioning using the WebVTT standard. While WebVTT is still in development, it provides a basic structure for captioning that, when full supported by browsers, will provide a universal format for all HTML5 video.

ARIA Design Patterns

ARIA (Accessible Rich Internet Applications) defines a way to make complex interactive widgets accessible. When building an ARIA-enhanced widget (such as a slider or complex menu), it is vital that the keyboard interaction with that element follow prescribed guidelines so the user knows how to interact with it. The ARIA Specification outlines  interaction design patterns for all ARIA elements.

Quick Contrast Checking

While WCAG 2.0 outlines specific requirements for contrast between text and background colors, these can sometimes be difficult to test, though tools make this easier. Common sense and some basic testing can usually be used to identify potential contrast issues. Printing the page on a black/white printer, decreasing your screen brightness (this is particularly helpful on mobile devices), and even squinting while viewing the page can make contrast issues more apparent.

Link and Button Roles

Buttons should only be used when form data is being submitted or when other in-page elements are being controlled or manipulated. Links, on the other hand, should be used when a context change will occur for the user - such as going to another page or jumping to another position within a page. Because links and buttons are identified differently by screen readers (e.g., "Search link" versus "Search button"), they should be used appropriately (i.e., links to do link functions and buttons to do button functions). Sometimes constraints may make it difficult to use the appropriate element. In these cases, role="link" or role="button" can be added to cause the element to be identified appropriately in screen readers.

Non-focusable Links

Links within a page are used to trigger an action, such as navigating to another web page or to another location within a page. The href attribute of the link generally defines where the link will navigate to. In modern web applications, the href attribute is often omitted and scripting is instead applied to links to cause them to perform an action. Links without an href attribute cannot be navigated to using the keyboard because the browser assumes the link has no function. Ensure that all interactive links have an href attribute or are given a tabindex="0" attribute so they can be navigated to using the keyboard.

Archived Web Accessibility Tips

 

get adobe reader

Related Topics

WebAIM Monthly Newsletter
About OK.gov | OK.gov Policies | Accessibility 
© The State of Oklahoma
Follow us On:
Twitter Facebook