Category Archives: web

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

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 |