Category Archives: web

The Section 508 Refresh is Here! 

We’re excited to announce that the U.S. Access Board has published its long-awaited update(link is external) to the federal regulations covering the accessibility of information and communications technology (Section 508) and telecommunications products and services (Section 255).

What are Section 508 and Section 255?

Section 508 of the Rehabilitation Act of 1973 applies to federal government agencies and the technology providers that sell to them. It requires that all information and communications technology (ICT) the federal government develops, procures, maintains, and uses be accessible to people with disabilities. This ensures that (1) Federal employees with disabilities have comparable access to, and use of, information and data relative to other federal workers, and (2) members of the public with disabilities receive comparable access to publicly-available information and services.

Section 508 applies to a wide range of technology products, including computer hardware and software, websites, video/multimedia products, phone systems, and copiers.

Section 255 of the Communications Act applies to telecommunications equipment manufacturers and service providers. It requires that telecommunications equipment and services be accessible to, and usable by, individuals with disabilities.

Why did the Access Board update these rules?

The Access Board updated and reorganized the Section 508 standards and Section 255 guidelines in response to market trends and innovations. Section 508 was last updated in 2000, and technology has evolved significantly since then. For example, in some cases different technological systems are now capable of performing similar tasks.

PEAT and other technology and disability experts anticipate that the updated rules will generate significant benefits for individuals with disabilities, including:

Curated by (Lifekludger)
Read full article at Source: The Section 508 Refresh is Here! | Partnership on Employment & Accessible Technology (PEAT)

The art of labelling — A11ycasts #12

There’s a lot of neat tricks in this video by Rob Dodson where he focuses on accessibility tricks in Chrome’s DevTools. A few notes:

  • Chrome DevTools has an experimental feature to help with accessibility testing that you can unlock if you head to chrome://flags/ and turn on in the DevTools settings.
  • Wrapping an <input type="checkbox"> in a <label>gives the input a name of the text in the label, even without a for attribute.
  • The aria-labelledby attribute overrides the name of the element with the text taken from a different element, referenced by ID. It can even compose a name together from multiple elements, including itself.
  • Adding tabindex='0' to an element will make it focusable.


Curated by (Lifekludger)
Read full article at css-tricks

What the Heck Is Inclusive Design? ◆ 24 ways

Recently, I’ve been using the term “inclusive design” and calling myself an “inclusive designer” a lot.

I’m not sure where I first heard it or who came up with it, but the terminology feels like a good fit for the kind of stuff I care to do when I’m not at a pub or asleep.

This article is about what I think “inclusive design” means and why I think you might like it as an idea.Isn’t ‘inclusive design’ just ‘accessibility’ by another name?

No, I don’t think so. But that’s not to say the two concepts aren’t…

curated by (Lifekludger)
Read full article at Source: What the Heck Is Inclusive Design? ◆ 24 ways

Introducing A11y Toggle

If you’re only here for the code, go straight to the GitHub repository.

A few weeks ago, I introduced a11y-dialog. Today, I am coming back with another accessibility-focused module: a11y-toggle.

At Edenspiekermann, we used to heavily rely on the checkbox hack to toggle content visibility. Unfortunately, this hack (the word is an understatement) involves some usability and accessibility concerns.

What’s wrong with the checkbox hack?

That’s a lot of people excluded just for the sake of simplicity (which is also arguable). On top of that, the checkbox hack has some accessibility issues. See, for a content toggle to be fully accessible to assistive technology users, it should respect the following:

So we need JavaScript (unfortunately). However, we don’t need a hell lot of it. A few lines are enough. And that’s precisely what a11y-toggle does (in roughly 300 bytes once gzipped). It just makes it work™.

 

Curated by (Lifekludger)
Read full article at Source

The Accessibility Difference Between Aria-hidden and role=”presentation”

In dealing with role=”presentation” and aria-hidden=”true” you may find that they both have deceptively similar functions when it relates to how they interact with assistive technology (screen readers). Before we dig into the difference between these two attributes we first need to learn a little bit about how accessibility in a Web browser works and this thing called: The Accessibility Tree

The Accessibility Tree

The accessibility tree is a mapping of objects within an HTML document that need to be exposed to assistive technology (if you’re familiar with the DOM, it’s a subset of the DOM). Anything that communicates aspects of the UI or has a property or relationship that needs to be exposed, gets added to the tree.

Curated by (Lifekludger)
Read full article at Source: The Accessibility Difference Between Aria-hidden and role=”presentation”

17 Adjustments You Can Make to Your Website  for Better Accessibility

Web developer Mary Gillen shares 17 adjustments you can make to your website today that make it more accessible to visitors with disabilities. WCAG 2.0

Curated by (Lifekludger)
Read full article at Source: 17 Adjustments You Can Make to Your Website Today That Make It More17 Website Adjustments You Can Make Today for Better Accessibility Accessible to Visitors with Disabilities |

How to Describe Complex Designs for Users with Disabilities – Salesforce UX

You’re a developer who has just been handed a complex design spec. You know the designs support accessibility because your UX team read a…

in Section 508 contains one very sage suggestion. It states that,

“… sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology.”

Originally written for software, these words are even more relevant today given the prevalence of web based applications. They describe the type of information users with disabilities need in order to successfully complete a task. This could be a blind user with a screen reader, a voice input user with a physical disability, or any number of other types of users with a variety of assistive technologies.

The basic fundamentals of making any interaction accessible with both the keyboard and for screen reader users comes down to providing three basic pieces of information: identity, operation, and state.

Users interacting with an element as basic as a checkbox, or as complex as drag and drop experience, have to consider these three questions:

Curated by (Lifekludger)
Read full article at Source: How to Describe Complex Designs for Users with Disabilities – Salesforce UX – Medium

Some tough love: Stop the excuses, already.

Over a year ago, Dale Cruse called me “militant” about accessibility. I know I use strong language at times, but I actively try to have a softer touch. I think he meant it kindly anyway…

The core Web technologies necessary to make web content accessible are not new. The needs of users with disabilities aren’t new. If any of these topics are new to you, that’s fine. Fucking learn them.

Curated by (Lifekludger)
Read full article at Source: Some tough love: Stop the excuses, already.

Dos and don’ts on designing for accessibility | Accessibility | Posters

Dos and don’ts on designing for accessibility

Karwai Pun, 2 September 2016 — Design, User research

Karwai Pun is an interaction designer currently working on Service Optimisation to make existing and new services better for our users. Karwai is part of an accessibility group at Home Office Digital, leading on autism, and has created these dos and don’ts posters as a way of approaching accessibility from a design perspective.

Dos and don’ts

The dos and don’ts of designing for accessibility are general guidelines, best design practices for making our services accessible. Currently, we have six different posters in our series that cater to users from these areas: low vision, deaf and hard of hearing, dyslexia, those with motor disabilities, users on the autistic spectrum and users of screen readers.

Curated by (Lifekludger)
Read full article at Source: Dos and don’ts on designing for accessibility | Accessibility