Link tags: a11y

231

sparkline

axe-con Digital Accessibility Conference | Deque

This looks like it’ll be a good event: a keynote from Vint Cerf and talks from Val Head, Rachel Andrew, Sara Soueidan, and others.

Best of all, it’s free!

Playing with Envision Glasses - Tink - Léonie Watson

The street finds its own uses for things, and it may be that the use for Google Glass is assistive technology. Here’s Léonie’s in-depth hands-on review of Envision Glasses, based on Google Glass.

The short wait whilst the image is processed is mitigated by the fact a double tap is all that’s needed to request another scene description, and being able to do it just by looking at what I’m interested in and tapping a couple of times on my glasses is nothing short of happiness in a pair of spectacles.

An opinionated guide to accessibility testing /// Iain Bean

  1. First impressions
  2. The Tab key
  3. Automated testing tools
  4. Screen reader testing
  5. Next steps

Not so short note on aria-label usage – Big Table Edition – HTML Accessibility

This is a very handy table of elements from Steve of where aria-label can be applied.

Like, for example, not on a div element.

Webbed Briefs

Heydon is back on his bullshit, making extremely entertaining and occassionally inappropriate short videos about web stuff.

WEBBED BRIEFS are brief videos about the web, its technologies, and how to make the most of them. They’re packed with information, fun times™, and actual goats. Yes, it’s a vlog, but it isn’t on Youtube. Unthinkable!

The pilot episode is entitled “What Is ARIA Even For?”

Accessibility Support

A very handy community project that documents support for ARIA and native HTML accessibility features in screen readers and browsers.

Van11y: Accessibility and Vanilla JavaScript - ES2015

Van11y (for Vanilla-Accessibility) is a collection of accessible scripts for rich interfaces elements, built using progressive enhancement and customisable.

How-to: Create accessible forms - The A11Y Project

Another five pieces of sweet, sweet low-hanging fruit:

  • Always label your inputs.
  • Highlight input element on focus.
  • Break long forms into smaller sections.
  • Provide error messages.
  • Avoid horizontal layout forms unless necessary.

5 most annoying website features I face as a blind person every single day by Holly Tuke

Five pieces of low-hanging fruit:

  • Unlabelled links and buttons
  • No image descriptions
  • Poor use of headings
  • Inaccessible web forms
  • Auto-playing audio and video

Top 5 things to review in an Accessible Design Review - Hassell Inclusion

Considering how much accessibility work happens “under the hood”, it’s interesting that all five of these considerations are visibly testable.

  1. Think about accessible copy
  2. Don’t forget about the focus indicator
  3. Check your colour contrast
  4. Don’t just use colour to convey meaning
  5. Design in anticipation of text resizing

On not choosing WordPress for the W3C redesign project - Working in the open with W3C and Studio 24

The use of React complicates front-end build. We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.

Schedule / Inclusive Design 24 (#id24) 17 September 2020

No matter what time zone you’re in, you can tune in to some excellent-sounding talks tomorrow.

No sign-up. No registration. All sessions are streamed live and publicly on the Inclusive Design 24 YouTube channel.

The difference between aria-label and aria-labelledby - Tink - Léonie Watson

A handy reminder from Léonie (though remember that the best solution is to avoid the problem in the first place—if you avoid using ARIA, do that).

Solid Start

A four-point checklist for inclusive design:

Are you a person that makes digital things for other people? Awesome—because this page is all about making things for people. There are four ways you can improve your creation for everybody. All four are testable, fixable and they improve usability for everybody.

We need more inclusive web performance metrics | Filament Group, Inc.

Good point. When we talk about perceived performance, the perception in question is almost always visual. We should think more inclusively than that.

Accessible to some - Manuel Matuzović

A score of 100 in Lighthouse or 0 errors in axe doesn’t mean that you’re done, it means that you’re ready to start manual testing and testing with real users, if possible.

Introduction to Screen Readers Using Voiceover | Gymnasium

This is a great short introduction to using VoiceOver with Safari by the one and only Ethan Marcotte.

Where did the focus go? | Amber’s Website

Amber documents a very handy bit of DOM scripting when it comes to debugging focus management: document.activeElement.

Striking a Balance Between Native and Custom Select Elements | CSS-Tricks

I think this a solution worthy of Solomon. In this case, the Gordian knot is the select element and its inevitable recreation in order to style it.

What if we instead deliver a native select by default and replace it with a more aesthetically pleasing one if possible? That’s where the “hybrid” select idea comes into action. It’s “hybrid” because it consists of two selects, showing the appropriate one at the right moment:

  • A native select, visible and accessible by default
  • A custom select, hidden until it’s safe to be interacted with a mouse

The implementation uses a genius combination of a hover media query and an adjacent sibling selector in CSS. It has been tested on a number of device/platform/browser combinations but more tests are welcome!

What I love about this solution is that it satisfies the stakeholders insisting on a custom component but doesn’t abandon all the built-in accessibility that you get from native form controls.