Skip to main content
Barrier-Free UX Experiences

Accessibility Guide for Developers

Illustration of a person working at desk building a website

Web/Application Developers

How Does Accessibility Apply to Me?

The standard Digital Accessibility practices for online websites and content still apply to web applications; e.g., images should have alternate text, color contrast should meet the proper ratio, etc. Visit our in-depth guides on general digital accessibility. When developing (or adopting) any kind of online tool, program, or software, there may be additional practices to keep in mind due to the versatile array of features an application may have compared to a static webpage.

With all digital accessibility, it’s important to make sure a tool or application is both:

  • Keyboard Accessible: a user can navigate the program through the keyboard only: no mouse.
  • Screen Reader Accessible: screen reader programs can easily read the content in the proper reading order.

Tools and applications can become much more complex than a simple website and require many different menus, buttons, and screens. It’s vital for a user to be able to navigate their application quickly and intuitively, regardless of what assistive technology they may be using. Two ways that can help achieve that goal are with proper HTML Elements and ARIA Labels.

HTML Elements

Always use the proper HTML attributes where applicable as these are often built to be accessible. For example, when you have a button, use a <button> instead of just making a <div> wrapped in an <a> tag.

ARIA Labels

Assigning the appropriate ARIA (Accessible Rich Internet Applications) roles and labels to HTML elements are crucial for your application to be accessible for keyboard and screen reader users.

  • aria-label: Used where there is no visual text with which to give an “accessible name” to an element for a non-visual user. Should be short and concise. (Example: writing aria-label=”Close” to represent the red “X” to close a dialogue box)
  • aria-labelledby: Used similarly to aria-label, but in cases where another element on the screen is (Example: having a checkbox element below a string of text that says “I Accept the Terms and Conditions.” The visual context is easy to understand for a visual user. Putting aria-labelledby=”id” onto the checkbox element with the id of the text element makes this context much clearer to someone using a screen reader)
  • aria-description: Similar to aria-label but used for more complex elements needing longer descriptions. (Example: using aria-description=”Calendar for current appointment availability” for an application that allows users to schedule their doctor appointment via online calendar)
  • aria-describedby: Similar to aria-describedby.

Common features that require these additional accessibility tags:

  • Tooltips
  • Popups/Modals
  • Form fields/Input
  • Drag/Drop

Tooltips

Tooltips – the text that appears when you hover over an object on the screen – aren’t natively accessible via keyboard alone or screen reader. Also keep in mind that users on a phone will not be able (this sentance needs to be finished)

  • On the element acting as the tooltip, add role="tooltip”. This makes sure that the tooltip properly activates both mouse and keyboard focus.
  • On the element that activates the tooltip, assign an aria-describedby that contains the id of the tooltip element. This tells the screen reader that there’s a tooltip attached to this element, as tooltips otherwise cannot receive keyboard focus or be tabbed to.

Popups/Modals

A popup or modal is described by a floating element that appears overtop other parts of the application and has any kind of user interactivity. A tooltip is not a popup because there is no way for a user to interact directly with the tooltip versus, say, a text box that appears and requires the user to click an “X” to close it.

  • On the element that activates the popup, add aria-haspopup. It can be set to one of seven values to specify the type of popup:
    • menu: indicates that the popup is a menu with a selection of items to be chosen
    • tree: indicates that the popup is a list of nested elements with some kind of hierarchy format
    • listbox: indicates that the popup is a list of static items to be selected by the user (such as a dropdown)
    • grid: indicates that the popup contains a grid of multiple cells with rows and columns, each of which are keyboard-focusable , such as in a tabular format
    • dialogue: indicates that the popup is a dialogue box that is (usually) separate from the rest of the application and must be interacted with in some way before returning to the app
    • true: defaults to menu
    • false: indicates there is no popup attached to this element
  • On the element that is acting as the popup, the proper role must be assigned, and it must match the aria-haspopup attribute.

Best Practices

  • Test as you build. Instead of waiting for the entire functional application to be done, test for accessibility with every new feature you intend to implement as you create it.
  • If possible, test your application with a screen reader like NVDA for Windows or Mac’s built-in VoiceOver.
  • Ensure proper focus order for keyboard users. Tabbing on the keyboard should go through all elements of your application in the proper, intended visual order.
  • Only use HTML elements as they were intended. For example, don’t style a radio button to look like it’s a normal “button” without the circle or use a navigation element for anything other than a menu.

Helpful Reminders While Building or Testing an Application

  • Are all buttons and interactive elements clear even without tooltips? Every visual icon should have a text alternative and be universally understood. Also keep in mind that phones and mobile devices also lack the ability to hover.
  • Can all elements (especially interactive elements) in your application be tabbed through with the keyboard in the proper visual order?

Scan your Website or Web Application with SiteImprove

UCF staff may obtain access to SiteImprove, a comprehensive tool that enhances website and web application quality by scanning for issues related to accessibility, content quality, and search engine optimization (SEO). It provides valuable insights that help improve user experience, ensure compliance with accessibility standards, and optimize content for better search engine rankings. Access can be requested by completing the SiteImprove Access Form.

Resources