Tags: a11y

225

sparkline

Saturday, February 15th, 2020

Standards for Writing Accessibly – A List Apart

  • Write Chronologically, Not Spatially
  • Write Left to Right, Top to Bottom
  • Don’t Use Colors and Icons Alone
  • Describe the Action, Not the Behavior

Friday, February 14th, 2020

A Complete Guide to Links and Buttons | CSS-Tricks

Chris takes two side-by-side deep dives; one into the a element, the other into the button element.

Even if you think you already know those elements well, I bet there’ll be something new here for you. Like, did you know that the button element can have form over-riding attributes like formaction, formenctype, formmethod, formnovalidate, and formtarget?

ARIA labels | Amber’s Website

A great explanation of aria-label and aria-labelledby!

Tuesday, February 4th, 2020

Could browsers fix more accessibility problems automatically?

Some really interesting ideas here from Hidde on how browsers could provide optional settings for users to override developers when it comes to accessibility issues like colour contrast, focus styles, and autoplaying videos.

Friday, December 13th, 2019

Why `details` is Not an Accordion - daverupert.com

At the risk of being a broken record; HTML really needs <accordion> , <tabs>, <dialog>, <dropdown>, and <tooltip> elements. Not more “low-level primitives” but good ol’ fashioned, difficult-to-get-consensus-on elements.

Hear, hear!

I wish browsers would prioritize accessibility improvements over things like main thread scheduling optimization to unblock tracking pixels and the Sisyphean task of competing with native.

If we really want to win, let’s make it easy for everyone to access the Web.

Wednesday, November 27th, 2019

Accessibility on The Session revisited

Earlier this year, I wrote about an accessibility issue I was having on The Session. Specifically, it was an issue with Ajax and pagination. But I managed to sort it out, and the lesson was very clear:

As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.

Well, fast forward to the past few weeks, when I was contacted by one of the screen-reader users on The Session. There was, once again, a problem with the Ajax pagination, specifically with VoiceOver on iOS. The first page of results were read out just fine, but subsequent pages were not only never announced, the content was completely unavailable. The first page of results would’ve been included in the initial HTML, but the subsequent pages of results are injected with JavaScript (if JavaScript is available—otherwise it’s regular full-page refreshes all the way).

This pagination pattern shows up all over the site: lists of what’s new, search results, and more. I turned on VoiceOver and I was able to reproduce the problem straight away.

I started pulling apart my JavaScript looking for the problem. Was it something to do with how I was handling focus? I just couldn’t figure it out. And other parts of the site that used Ajax didn’t seem to be having the same problem. I was mystified.

Finally, I tracked down the problem, and it wasn’t in the JavaScript at all.

Wherever the pagination pattern appears, there are “previous” and “next” links, marked up with the appropriate rel="prev" and rel="next" attributes. Well, apparently past me thought it would be clever to add some ARIA attributes in there too. My thinking must’ve been something like this:

  • Those links control the area of the page with the search results.
  • That area of the page has an ID of “results”.
  • I should add aria-controls="results" to those links.

That was the problem …which is kind of weird, because VoiceOver isn’t supposed to have any support for aria-controls. Anyway, once I removed that attribute from the links, everything worked just fine.

Just as the solution last time was to remove the aria-atomic attribute on the updated area, the solution this time was to remove the aria-controls attribute on the links that trigger the update. Maybe this time I’ll learn my lesson: don’t mess with ARIA attributes you don’t understand.

Sunday, November 17th, 2019

A Web Developers New Working Week

I think these are great habit-forming ideas for any web designer or developer: a day without using your mouse; a day with your display set to grayscale; a day spent using a different web browser; a day with your internet connection throttled. I’m going to try these!

Thursday, November 7th, 2019

What I’ve learned about accessibility in SPAs

Nolan writes up what he learned making accessibiity improvements to a single page app. The two big takeways involve letting the browser do the work for you:

Here’s the best piece of accessibility advice for newbies: if something is a button, make it a <button>. If something is an input, make it an <input>. Don’t try to reinvent everything from scratch using <div>s and <span>s.

And then there are all the issues that crop up when you take over the task of handling navigations:

  • You need to manage focus yourself.
  • You need to manage scroll position yourself.

For classic server-rendered pages, most browser engines give you this functionality for free. You don’t have to code anything. But in an SPA, since you’re overriding the normal navigation behavior, you have to handle the focus yourself.

Friday, October 25th, 2019

Why Are Accessible Websites so Hard to Build? | CSS-Tricks

I reckon a lot of websites have bad accessibility not because folks don’t care, but because they don’t know there’s an issue in the first place.

The headline is begging the question (I don’t think accessible websites are so hard to build), but I agree with Robin’s idea:

What if our text editors caught accessibility issues and showed them to us during development?

This is something that Hidde has been talking about recently too, looking at content management systems.

Wednesday, October 16th, 2019

Beyond automatic accessibility testing: 6 things I check on every website I build - Manuel Matuzović

Six steps that everyone can do to catch accessibility gotchas:

  1. Check image descriptions
  2. Disable all styles
  3. Validate HTML
  4. Check the document outline
  5. Grayscale mode
  6. Use the keyboard

Friday, October 4th, 2019

Designing a focus style | Zell Liew

A deep dive info focus styles with this conclusion:

The default focus ring works. There are problems with it, but it can be good enough, especially if you can’t dedicate time and energy to create a custom focus ring.

Saturday, August 31st, 2019

Wednesday, August 21st, 2019

Accessibility and web performance are not features, they’re the baseline | CSS-Tricks

Performance and accessibility aren’t features that can linger at the bottom of a Jira board to be considered later when it’s convenient.

Instead we must start to see inaccessible and slow websites for what they are: a form of cruelty. And if we want to build a web that is truly a World Wide Web, a place for all and everyone, a web that is accessible and fast for as many people as possible, and one that will outlive us all, then first we must make our websites something else altogether; we must make them kind.

Saturday, August 10th, 2019

Amphora. — Ethan Marcotte

There’s no sugar-coating it—AMP components are dreadfully inaccessible:

We’ve reached a point where AMP may “solve” the web’s performance issues by supercharging the web’s accessibility problem, excluding even more people from accessing the content they deserve.

Tuesday, July 30th, 2019

Sunday, July 21st, 2019

Maybe You Don’t Need a Date Picker | Adrian Roselli

In some situations, a date picker is overkill:

I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc — it has tested well.

5 Keys to Accessible Web Typography | Better Web Type

Some excellent explanations for these five pieces of sensible typography advice:

  1. Set your base font size in relative units
  2. Check the colour of your type and only then its contrast
  3. Use highly legible fonts
  4. Shape your paragraphs well
  5. Correctly use the heading levels

Tuesday, July 16th, 2019

Initial thoughts on standardizing form controls | Greg Whitworth

Greg has done a lot of research into developer frustrations with customising form controls.

My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.

Tuesday, June 18th, 2019

How to Section Your HTML | CSS-Tricks

A deep dive with good advice on using—and labelling—sectioning content in HTML: nav, aside, section, and article.

Monday, June 17th, 2019

Drop caps & design systems - Vox Product Blog

Sit down and listen to a story from uncle Ethan.