Tags: aria

167

sparkline

Tuesday, December 13th, 2022

Mona Sans & Hubot Sans

Two new lovely open source variable fonts from Github.

Sunday, October 30th, 2022

Overloading buttons

It’s been almost two years since I added audio playback on The Session. The interface is quite straightforward. For any tune setting, there’s a button that says “play audio”. When you press that button, audio plays and the button’s text changes to “pause audio.”

By updating the button’s text like this, I’m updating the button’s accessible name. In other situations, where the button text doesn’t change, you can indicate whether a button is active or not by toggling the aria-pressed attribute. I’ve been doing that on the “share” buttons that act as the interface for a progressive disclosure. The label on the button—“share”—doesn’t change when the button is pressed. For that kind of progressive disclosure pattern, the button also has an aria-controls and aria-expanded attribute.

From all the advice I’ve read about button states, you should either update the accessible name or change the aria-pressed attribute, but not both. That would lead to the confusing situation of having a button labelled “pause audio” as having a state of “pressed” when in fact the audio is playing.

That was all fine until I recently added some more functionality to The Session. As well as being able to play back audio, you can now adjust the tempo of the playback speed. The interface element for this is a slider, input type="range".

But this means that the “play audio” button now does two things. It plays the audio, but it also acts as a progressive disclosure control, revealing the tempo slider. The button is simultaneously a push button for playing and pausing music, and a toggle button for showing and hiding another interface element.

So should I be toggling the aria-pressed attribute now, even though the accessible name is changing? Or is it enough to have the relationship defined by aria-controls and the state defined by aria-expanded?

Based on past experience, my gut feeling is that I’m probably using too much ARIA. Maybe it’s an anti-pattern to use both aria-expanded and aria-pressed on a progressive disclosure control.

I’m kind of rubber-ducking here, and now that I’ve written down what I’m thinking, I’m pretty sure I’m going to remove the toggling of aria-pressed in any situation where I’m already toggling aria-expanded.

What I really need to do is enlist the help of actual screen reader users. There are a number of members of The Session who use screen readers. I should get in touch and see if the new functionality makes sense to them.

Sunday, October 16th, 2022

How to (not) make a button - Tomas Pustelnik’s personal website

A demonstration of how even reinventing a relatively simple wheel takes way more effort than it’s worth when you could just use what the brower gives you for free.

Thursday, October 13th, 2022

Fontshare: Quality Fonts. Free.

A whole lotta nice fonts—most of them variable fonts—from Indian Type Foundry.

Tuesday, October 4th, 2022

Style with Stateful, Semantic Selectors

I’ve done this quite a bit: using ARIA attributes as “hooks” for styling and behaviour. It’s a way of thinking of accessibility as the baseline to build upon rather than something that can sprinkled on top later.

Tuesday, August 30th, 2022

Bring Focus to the First Form Field with an Error :: Aaron Gustafson

A handy little script from Aaron to improve the form validation experience.

Monday, July 25th, 2022

Control

In two of my recent talks—In And Out Of Style and Design Principles For The Web—I finish by looking at three different components:

  1. a button,
  2. a dropdown, and
  3. a datepicker.

In each case you could use native HTML elements:

  1. button,
  2. select, and
  3. input type="date".

Or you could use divs with a whole bunch of JavaScript and ARIA.

In the case of a datepicker, I totally understand why you’d go for writing your own JavaScript and ARIA. The native HTML element is quite restricted, especially when it comes to styling.

In the case of a dropdown, it’s less clear-cut. Personally, I’d use a select element. While it’s currently impossible to style the open state of a select element, you can style the closed state with relative ease. That’s good enough for me.

Still, I can understand why that wouldn’t be good enough for some cases. If pixel-perfect consistency across platforms is a priority, then you’re going to have to break out the JavaScript and ARIA.

Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling select elements. That’s one of the reasons why the work being done by the Open UI group is so important.

But there’s one more component: a button.

Again, you could use the native button element, or you could use a div or a span and add your own JavaScript and ARIA.

Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.

I’ve been trying to understand the mindset of a developer who wouldn’t use a native button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.

I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.

When I hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).

But I now understand that someone else might hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.

I get it. I don’t agree. But I get it.

If your background is in computer science, then the ability to precisely predict how a programme will behave is a virtue. Any potential side-effects that aren’t within your control are undesirable. The only way to ensure that an interface will behave exactly as you want is to write it entirely from scratch, even if that means using more JavaScript and ARIA than is necessary.

But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.

Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using div, JavaScript and ARIA. It’s not what I would do, but I think I understand the motivation a bit better now.

Tuesday, June 7th, 2022

Patterns | APG | WAI | W3C

This is a terrific resource! A pattern library of interactive components: tabs, switches, dialogs, carousels …all the usual suspects.

Each component has an example implementation along with advice and a checklist for ensuring its accessible.

It’s so great to have these all gathered together in one place!

Saturday, May 7th, 2022

Roboto … But Make It Flex - Material Design

This version of Roboto from Font Bureau is a very variable font indeed.

Monday, January 31st, 2022

Fluid type sizes and spacing — Piper Haywood

Prompted by Utopia, Piper shares her methodology for fluid type in Sass.

Thursday, December 30th, 2021

Manrope – free sans-serif variable font

This font is a crossover of different font types: it is semi-condensed, semi-rounded, semi-geometric, semi-din, semi-grotesque. It employs minimal stoke thickness variations and a semi-closed aperture.

Monday, September 20th, 2021

In Quest of Search

On the surface this is about the pros and cons of minting a new HTML search element to replace div role="search" but there’s a deeper point which is that, while ARIA exists to the plug the gaps in HTML, the long-term goal is to have no gaps.

ARIA is not meant to replace HTML. If anything, the need to use ARIA as ‘polyfill’ for HTML semantics could be considered as a sign and a constant reminder of the fact that HTML falls short on some semantics that benefit users of assistive technologies.

Tuesday, September 14th, 2021

Accessibility testing

I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.

While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.

Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.

Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated label element (using the for and id attributes); images that don’t have alt text; pages that don’t have sensible heading levels or landmark regions like main and nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings, alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated: alt text for images; labels for inputs.

Then there’s interactive stuff. If you only use native HTML elements you’re probably in the clear, but chances are you’ve got some bespoke interactivity on your site: a carousel; a mega dropdown for navigation; a tabbed interface. HTML doesn’t give you any of those out of the box so you’d need to make your own using a combination of HTML, CSS, JavaScript and ARIA. There’s plenty of testing you can do before launching—I always ask myself “What would Heydon do?”—but these components really benefit from being tested by real screen reader users.

So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.

If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.

If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.

When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.

Wednesday, August 18th, 2021

MD Nichrome by Mass-Driver

Marvin has some competition! Here’s another beautiful sci-fi variable font:

MD Nichrome is a display typeface based on the typography of paperback science fiction from the 70s and early 80s.

Monday, July 19th, 2021

Solarpunk

My talk on sci-fi and me for Beyond Tellerrand’s Stay Curious event was deliberately designed to be broad and expansive. This was in contrast to Steph’s talk which was deliberately narrow and focused on one topic. Specifically, it was all about solarpunk.

I first heard of solarpunk from Justin Pickard back in 2014 at an event I was hosting. He described it as:

individuals and communities harnessing the power of the photovoltaic solar panel to achieve energy-independence.

The sci-fi subgenre of solarpunk, then, is about these communities. The subgenre sets up to be deliberately positive, even utopian, in contrast to most sci-fi.

Most genres ending with the -punk suffix are about aesthetics. You know the way that cyberpunk is laptops, leather and sunglasses, and steampunk is zeppelins and top hats with goggles. Solarpunk is supposedly free of any such “look.” That said, all the examples I’ve seen seem to converge on the motto of “put a tree on it.” If a depiction of the future looks lush, verdant, fecund and green, chances are it’s solarpunk.

At least, it might be solarpunk. It would have to pass the criteria laid down by the gatekeepers. Solarpunk is manifesto-driven sci-fi. I’m not sure how I feel about that. It’s one thing to apply a category to a piece of writing after it’s been written, but it’s another to start with an agenda-driven category and proceed from there. And as with any kind of classification system, the edges are bound to be fuzzy, leading to endless debates about what’s in and what’s out (see also: UX, UI, service design, content design, product design, front-end development, and most ironically of all, information architecture).

When I met up with Steph to discuss our talk topics and she described the various schools of thought that reside under the umbrella of solarpunk, it reminded me of my college days. You wouldn’t have just one Marxist student group, there’d be multiple Marxist student groups each with their own pillars of identity (Leninist, Trotskyist, anarcho-syndicalist, and so on). From the outside they all looked the same, but woe betide you if you mixed them up. It was exactly the kind of situation that was lampooned in Monty Python’s Life of Brian with its People’s Front of Judea and Judean People’s Front. Steph confirmed that those kind of rifts also exist in solarpunk. It’s just like that bit in Gulliver’s Travels where nations go to war over the correct way to crack an egg.

But there’s general agreement about what broadly constitutes solarpunk. It’s a form of cli-fi (climate fiction) but with an upbeat spin: positive but plausible stories of the future that might feature communities, rewilding, gardening, farming, energy independence, or decentralisation. Centralised authority—in the form of governments and corporations—is not to be trusted.

That’s all well and good but it reminds of another community. Libertarian preppers. Heck, even some of the solarpunk examples feature seasteading (but with more trees).

Politically, preppers and solarpunks couldn’t be further apart. Practically, they seem more similar than either of them would be comfortable with.

Both communities distrust centralisation. For the libertarians, this manifests in a hatred of taxation. For solarpunks, it’s all about getting off the electricity grid. But both want to start their own separate self-sustaining communities.

Independence. Decentralisation. Self-sufficiency.

There’s a fine line between Atlas Shrugged and The Whole Earth Catalog.

Monday, March 29th, 2021

CSS { In Real Life } | Quick Tip: Style Pseudo-elements with Javascript Using Custom Properties

Oh, this is smart! You can’t target pseudo-elements in JavaScript, but you can use custom properties as a proxy instead.

Wednesday, March 24th, 2021

Show/Hide password accessibility and password hints tutorial | Part of a Whole

A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.

Wednesday, March 17th, 2021

Building Dark Mode | Product Blog • Sentry

Robin makes a good point here about using dark mode thinking as a way to uncover any assumptions you might have unwittingly baked into your design:

Given its recent popularity, you might believe dark mode is a fad. But from a design perspective, dark mode is exceptionally useful. That’s because a big part of design is about building relationships between colors. And so implementing dark mode essentially forced everyone on the team to think long, hard, and consistently about our front-end design components. In short, dark mode helped our design system not only look good, but make sense.

So even if you don’t actually implement dark mode, acting as though it’s there will give you a solid base to build in.

I did something similar with the back end of Huffduffer and The Session—from day one, I built them as though the interface would be available in multiple languages. I never implemented multi-language support, but just the awareness of it saved me from baking in any shortcuts or assumptions, and enforced a good model/view/controller separation.

For most front-end codebases, the design of your color system shows you where your radioactive styles are. It shows you how things are tied together, and what depends on what.

Good, Better, Best: Untangling The Complex World Of Accessible Patterns — Smashing Magazine

I really like the approach that Carie takes here. Instead of pointing to specific patterns to use, she provides a framework for evaluating technology. Solutions come and go but this kind of critical thinking is a long-lasting skill.

Monday, March 1st, 2021

Proxima Vara by Mark Simonson

Oh, nice! A version of the classic Proxima Nova that’s a variable font that allows you to vary weight, width, and slant.