Websites and Applications

Redesigning for Cognitive Ease

Alyssa Panetta has been designing and developing websites by hand since Y2K. She has worked for educational mathematics software companies and is currently a web designer/developer for the University Libraries, University at Albany. 

After a diagnosis of brain cancer in 2020 and subsequent treatment, Alyssa started a website called dear talula, where she writes letters to her removed tumor, which is preserved in a tumor research bank. 


Accessible Rich Internet Applications (ARIA) is a set of attributes that define  ways to make web content and applications (especially those with JavaScript) more accessible to people with disabilities. But native HTML elements have built-in keyboard accessibility, roles, and states.

If you choose to use ARIA instead or in addition, you are responsible for mimicking the equivalent browser behavior in script. If you are not a developer, you will need one to implement ARIA.


ARIA tags can greatly enhance accessibility, usability, and navigability for screen reader and screen magnification users. Developers can use it to incorporate accessibility into both new and legacy pages.

ARIA supplements HTML so that interactions and widgets commonly used in applications can be passed to assistive technologies when there is no other mechanism.


Dos and Don'ts

Dos and Don'ts

Expand all

Dos and Don'ts

Use Native HTML When Possible

HTML, when implemented correctly, conveys the semantic meaning of the content to people using assistive technology (such as screen readers) without any additional effort because it is already mapped to the accessibility APIs.


Use HTML elements.


Don't use ARIA when an HTML element is available.

Don't change native semantics unless it is essential.

Make ARIA Controls Usable With a Keyboard

ARIA overrides certain HTML attributes and functions. It also provides custom control semantics, but the control won't work as expected with a keyboard.


Use ARIA and JavaScript to make custom controls accessible with a keyboard.


Don't use role="presentation" or aria-hidden="true" on a focusable element.

The ARIA-hidden attribute is intended to hide the content or element from the accessibility APIs and the element that has ARIA-hidden set to true is not supposed to be interactive in any way. Defining either of these attributes on the visible focusable elements results in some users focusing on nothing.

Include Accessible Names With Interactive Elements

Interactive elements such as but not limited to the following must have accessible names:

  • Links
  • Buttons
  • Text fields
  • Combo boxes
  • Radio buttons
  • Checkboxes

Without an accessible name, assistive technologies do not understand what the control does.


Do use varying techniques to provide accessible names, which vary from control to control.

Some Techniques for Providing Accessible Names
Control Technique
HTML links and buttons The link text or button value becomes the accessible name.
Input text fields Associate a form control with its visible label either implicitly or explicitly.
Custom widgets Use ARIA-label or ARIA-labelledby.



Don't include an interactive element with a visible label but no accessible name.

Data Visualization

How to present data in an inclusive and accessible manner has been a session request for a while. Unfortunately, it has proven difficult to find speakers with experience in this area. Thankfully, this month we are joined by Neha Bansal, senior director of application development in the Office of Information Technology, to discuss accessibility in data visualization.