Category Archives: web

We need to talk about Accessibility on Chatbots

What happens when a blind person wants to use your chatbot?

This idea started after I did a research on UX for autonomous cars or self-driving cars. I did some interviews with 4 people, one of them being blind. I was really surprised to know that she can fully take care of herself and go around using her phone and guide dog. She uses her phone and her dog as interfaces to do something that (unfortunately) she is not able to.

After the interviews, I started my UX research and then, another surprise: the aspects of UX for self-driving cars — which I noticed basically two:

  • Visual design — “how can we let people know what the car sees?” Tons of (interesting) concepts of visual design to let people understand and see what the car sees while it’s driving itself.
  • Affordances — “How can we make people interact with the car?” I have seen nice buttons, panels and clues that help people interact with the cars.

With those two main aspects in mind, I started questioning myself:

What about blind people? How will they use self-driving cars?

Curated by (Lifekludger)
Read full article at Source: We need to talk about Accessibility on Chatbots

Developers: get started with web accessibility

If web accessibility is new to you, the path ahead can seem overwhelming.

If web accessibility is new to you, the path ahead can seem overwhelming.

It’s not so bad. I promise!

You could chase perfection forever by building accessible products for every user imaginable. That’s no different from design and development more generally: there’s always room for improvement.

But when it comes to usability — and that includes accessibility — a product doesn’t need to be perfect to be practical. Even small changes can make a big difference.

So here are some tips for how to get started. This guide is written for front-end web developers who are new to accessibility, and it’s by no means comprehensive — but I hope it will help you start a longer journey of learning.

Curated by (Lifekludger)
Read full article at Source: Developers: get started with web accessibility – Medium

Writing HTML with accessibility in mind

Writing HTML with accessibility in mind

An introduction to web accessibility. Tips on how to improve your markup and provide users with more and betters ways to navigate and interact with your site. If you don’t want to read the preface, jump right to the tips.

Personal development and change in perspective When I made my first website my highest priority was to get content online. I didn’t care much about usability, accessibility, performance, UX or browser compatibility. Why would I? …

If you don’t want to read the preface, jump right to the tips.

Personal development and change in perspective

When I made my first website my highest priority was to get content online. I didn’t care much about usability, accessibility, performance, UX or browser compatibility. Why would I? I made a robust table based layout and I offered a 800×600 and a 1024×768 version of my site. On top of that, I informed users that the website was optimized for Internet Explorer 5.

This was of course before I started to work professionally as a web designer and my perspective in what was important changed.

Years later, instead of dictating the requirements for my websites, I started to optimize them for all major browsers.

Beginning with Ethan Marcotte’s game changing article I started caring about devices as well.

Making websites for all kinds or browsers and devices is great, but pretty much useless if the websites are too slow. So I learned everything about critical CSS, speed indices, font loading, CDNs and so on.

Getting started with accessibility (a11y)


But accessibility isn’t just yet another item on our to-do list to cross off before we launch our website. Accessibility is the foundation of what we do as web designers and web developers and it’s our obligation to treat it as such.

I spent the last few months reading, listening and talking about web accessibility. It took me some time to get my head around a few things and I’m still at the beginning, but the more I learn the more I’m surprised how much I can do right now without having to learn anything completely new.

In this series of articles, I want to share some of my newly acquired knowledge with you. You shouldn’t treat the tips I’m going to give you as a check list but as a starting point. Incorporating these techniques into your workflow will get you started with accessibility and hopefully motivate you to learn and care more about your users.


Without further ado, here are my accessibility tips:

Source: Writing HTML with accessibility in mind – Medium

Designing Safer Web Animation For Motion Sensitivity

Val Head suggests accessible animation techniques to avoid triggering dizziness in users with inner ear and balance disorders.

It’s no secret that a lot of people consider scrolljacking and parallax effects annoying and overused. But what if motion does more than just annoy you? What if it also makes you ill?

That’s a reality that people with visually-triggered vestibular disorders have to deal with. As animated interfaces increasingly become the norm, more people have begun to notice that large-scale motion on screen can cause them dizziness, nausea, headaches, or worse. For some, the symptoms can last long after the animation is over. Yikes.

The idea that animation in our interfaces is capable of making our users dizzy wasn’t something we had to contend with much when the web was predominantly a static medium. It’s actually a fairly new revelation in most tech circles. Even Apple discovered this the hard way when the animated transitions in iOS 7 started making some people sick. Just like other elements of design, the way you use animation can have an impact on how accessible the end product is to your audience, especially if they suffer from a vestibular disorder.

Curated by (Lifekludger)
Read full article at Source: Designing Safer Web Animation For Motion Sensitivity

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