# Accessibility

Accessibility is something often disregarded in modern web development, but it is crucial to delivering the best experience to all of your users.

# Minimum Accessibility Guidelines

At the very minimum every website should meet the following guidlines:

• You should be able to tab through your site
  Radio buttons that are hidden in favour of nicely styled labels with sibling selectors should be positioned off screen rather than display: none; as this prevents them being tabbed through
  tabindex=”-1” on inputs that need to be skipped, such as honeytraps.
  Skip to content – use a hidden <a href=”#content”>Skip to content</a> anchor. Alternatively use: http://paypal.github.io/skipto/
  
  
• Any interactive elements (eg. carousels with keyboard controls) should be focusable (tabindex="0")
  
  
• All images should have an alt tag (even if it’s content is empty)
  Use alt text on all images except: spacers, icons, purely decorative, tests and CAPTCHA images.
  If labels contain an <svg> instead of text you can use aria-labelledby to describe what the label should say.
  
  
• All controls should have a label
  Jump to 'Fifth rule of ARIA' for more
  
  
• Custom controls should have a role attribute
  
  
• Custom controls should properly convey their state
  
  
• The flow of DOM elements should make sense if you use CSS to reorder content
  
  
• Heading hierarchy (h1-h6) should be used properly
  No more than a single h1 on a page
  No jumps in hierarchy (eg. h1 to h3)**
  
  
• Colour contrasts should be WCAG AA compliant
  Colour Contract Checker
  
  
• Focus styling should not be removed, unless it is for mouse interaction exclusively
  Consider using :focus-visible if you’re considering using outline: none; on :focus.
  

# Additional Accessibility Best Practises

The following are some ideal best practises that are not critical, but will vastly increase the UX for a lot of users:

• Keyboard functionality / shortcuts should be implemented wherever possible / logical
• Toggle the ability to focus content based on its visibility (eg expanding navigation)
• SVGs and other non-image tag icons should have a label visible to a screen reader (Maybe use title, as it offers a hover for those who can’t determine the message of the icon)
• Interactive elements like links and buttons should indicate their purpose and state, ideally, every interactive button should have a hover state
• Use landmark elements and roles so users can bypass repetitive content
• Use aria-describedby in forms on information related to specific fields (eg. "Password must contain a special character")
• Use aria-live for updates and notification boxes so screen reader users will automatically be read out updates without having to focus them
• Colour contrasts should be WCAG AAA compliant
• Additional skip links
• autocomplete="" allows browsers to autocomplete fields from a user's saved preferences: https://www.w3.org/TR/WCAG21/#input-purposes

# Landmark roles

Adding ARIA landmarks to your existing site, or to a site you are developing, provides useful global navigation features and aids understanding of content structure for users. Over time the necessity of explicitly assigning landmarks will lessen as browsers build in ARIA landmark roles to newer HTML element semantics. There is widespread support for ARIA landmarks in browsers and screen readers. https://developer.paciellogroup.com/blog/2013/02/using-wai-aria-landmarks-2013/#tablex

# ARIA

Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities.

It supplements HTML so that interactions and widgets commonly used in applications can be passed to Assistive Technologies when there is not otherwise a mechanism. For example, ARIA enables accessible navigation landmarks in HTML4, JavaScript widgets, form hints and error messages, live content updates, and more.

# First Rule of ARIA Use

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

# Second Rule of ARIA Use

Do not change native semantics, unless you really have to. For example: Developer wants to build a heading that's a tab.

# Third Rule of ARIA Use

All interactive ARIA controls must be usable with the keyboard. If you create a widget that a user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard. All interactive widgets must be scripted to respond to standard keystrokes or keystroke combinations where applicable. For example, if using role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key.

# Fourth Rule of ARIA Use

Do not use role="presentation" or aria-hidden="true" on a focusable element. Using either of these on a focusable element will result in some users focusing on 'nothing'.

# Fifth Rule of ARIA Use

All interactive elements must have an accessible name. An interactive element only has an accessible name when its Accessibility API accessible name (or equivalent) property has a value.

<label for="userName">User Name</label>
<input type="text" id="userName" />

or

<input type="text" aria-label="User Name" />

or

<span id="p1">user name</span>
<input type="text" aria-labelledby="p1" />

# Common ARIA attributes