Tagged “accessibility”

I loved this insight into Adam Silver’s thought process. And it came at a timely moment since at work I’m currently trying to promote evidence-based, considered choices regarding user interface patterns.

My summary of Adam’s key points is:

• he found a UI pattern (let’s call it pattern x) in his project and flagged that while it’s not always bad it risks numerous usability problems. He lists these problems.
• he advises that pattern x is beneficial only in very specific situation y
• and that otherwise, pattern x is unnecessary and a more basic solution would not only require less work but provide a better user experience
• given this context, he asks others working on the project the following:
  • can they explain why pattern x was used?
  • did research (really) indicate a need? (this implicitly also asks if evidence or research was considered at all)
  • what else was tried beforehand? (this also subtly checks for awareness of the risks of pattern x and whether other options were even considered)
  • even if the use case was appropriate, given the downsides of pattern x were you comfortable the benefits outweigh those?

Adam also mentions how on this occasion, in the end, he had to grudgingly stick with pattern x because even though there were possible alternatives, his team didn’t have time to research or implement them. A familiar dose of real life, there. It’s worth being clear, though, that their implementation of pattern x (an accordion) is at least accessible, since as far as I can tell it uses their modern accordion design system component. If that were not the case, I imagine it’d be even less viable to leave it in place.

Hard to argue with Brad’s logic.

Right now, vast numbers of human beings are devoting their time and energy to designing, building, documenting, and maintaining the exact same set of common components.

Our efforts to reduce duplicative work at the individual level are resulting in duplicative work at the inter-organization level.

A Global Design System would improve the quality and accessibility of the world’s web experiences, save the world’s web designers and developers millions of hours, and make better use of our collective human potential.

A Global Design System would exist as a standalone library of components that consumers would pull into their projects, style to match their brand/visual language, and integrate into their application’s business logic. Not only would this be far more efficient than having to design, build, test, deploy, and integrate bespoke components from scratch, a Global Design System would give teams added confidence that the components are sturdy and reliable.

Adrian recommends that we underline links in body copy and provides a host of evidence and rationale to back that up.

WCAG guidelines tell us to make sure we do not rely on color alone to distinguish links and even explicitly suggest underlines.

Usability researchers and practitioners generally suggest that underlines are the most clear way to indicate a link that lives within content.

Academic researchers confirm that … when you have them you can reduce additional cognitive load by making them apparent. Underlines performed well.

There are other sites on the web which have set expectations, but many of them likely do not correspond directly to your own circumstance. Additionally, some of them are already violating WCAG, which removes them from consideration as appropriate analogues.

Other styling options can work, but they are not necessarily universal, sometimes requiring users to learn them. They may also conflict with other styles on your site, increasing the effort (cost) for you to come up with usable, novel and progressive indicators.

Given all these factors, I recommend you underline links in your body content.

Here’s Eric Bailey with some very relatable thoughts on the need to tell design system stories even though it’s difficult.

The component works. And because it works, nobody pays attention to it.

This is the promise of a design system made manifest: Consistent, quality experiences for complicated interactions, distributed at scale with minimal fuss.

This is objectively great. The problem, however, is how we talk, or fail to talk about this type of success.

A lack of bug reports, accessibility issues, design tweaks, etc. are all objectively great, but there are no easy datapoints you can measure here. By this, I mean it is difficult to quantify a void.

Eric advices crafting stories about the important aspects of design system work that are not directly about components:

• Identifying and collecting various ways to weave compelling narratives about the invisible, successful work you’ve done, and then
• Putting those stories in front of the people who need to know them.

At work we are currently working on that very thing as part of a communication strategy.

Sidenote: Eric frames all this in the context of a Data table component he recently worked on for GitHub. It looks good! This is also highly relatable, because I built one of these a few years back, too, and know how much work is involved.

Question: when presenting users with a means of downloading a file, should you use the anchor element or the button element?

Answer: you should use the anchor element.

Eric starts by quoting accessibility expert Scott O’Hara to explain why anchor is the appropriate element:

The debate about whether a button or link should be used to download a file is a bit silly, as the whole purpose of a link has always been to download content. HTML is a file, and like all other files, it needs to be retrieved from a server and downloaded before it can be presented to a user.

The confusion seems to come from developers getting super literal with the “links go places, buttons perform actions.” Yes, that is true, but links don’t actually go anywhere. They retrieve information and download it.

Long story short, the download attribute is unique to anchor links for a reason. download augments the inherent functionality of the link retrieving data. It side steps the attempt to render the file in the browser and instead says, “You know what? I’m just going to save this for later…”

Eric follows up by suggesting that as designers and developers we should make the experience of interacting with a download link as good as possible. To that end:

• Ensure it looks like a link, i.e. underlined. You’re using a link (because it’s semantically appropriate) so now encourage the appropriate perceived affordances via conventional visual design for a link
• Use verb plus noun for the text. For example, Download fonts
• Include the file size (for example 34 MB) to give an indication of the download time
• Consider adding an indicator that the link does something other than take you to another place on your website. A downward-facing arrow is conventional

When asking users for numbers and dates, which HTML form elements should we use?

When asking the user for numeric information it might feel obvious to use the HTML input type meant for that purpose, namely number.

However the UK GDS wrote in 2020 that they had switched to using inputs of type text, with inputmode set to numeric. This was after conducting tests which had revealed a variety of usability and accessibility issues.

In the same article a reader questioned why GDS’s use of text inputs also extended to gathering dates (a subset of numbers) when there is a dedicated input type date for that purpose. GDS answered that there are accessibility and usability problems with browser implementations of <input type"date"> and linked to Hassell Inclusion’s 2019 article on date inputs as evidence.

I love the level of research and detail that the GDS and Hassell articles provide. But the notion of not using the HTML elements meant for the job annoys me. I’m also aware that smart developers like Jeremy Keith note that input type date now has wide browser support and are using it. (Update: it seems Jeremy has found some browser support issues too.)

It’s also worth reiterating that the Hassell article is from 2019 and the GDS one from 2020, and four or five years is a long time in browser support.

So what should we do, and how should we make the decision? I’m gonna circle back to this and update it with some answers soon, once I’ve worked them out.

Whitney Lewis covers four accessibility considerations for implementing forms: autofill, error messaging, date fields and auto-formatting fields.

I found the explanatations of the autocomplete attribute and the section on an accessible error message pattern particularly useful. The latter part felt similar to the good advice Adam Silver gives in his book Form Design Patterns.

Nathan on how complex components require comprehensive specifications rather than ill-advised assumptions, and how Figma can be used to guide engineers to reliably build such components.

I’m still amazed when designers schlep together a few pictures, publish a configurable Figma component, point their developer counterparts at the main component and say “Use Figma’s inspect tool.”

Things have changed. Components are more complicated. Designers are delivering to many different developers. Accessibility has risen to the fore. For design systems that scale, teams are finding it necessary to write down all the details again.

At work in our project to improve our component documentation across the component life-cycle, we’ve been following Nathan’s advice and using his plug-in to assist with the “specification” aspect.

Adam Silver’s collection of accessible form-related components – a companion to his book Form Design Patterns – is a brilliant reference.

In there you’ll find Autocomplete, date fields, validation and lots of other tricky components and patterns.

Absolute gold here regarding accessibility, bloated components, and purpose versus appearance.

It’s easy for a component to become bloated and its purpose increasingly ambiguous.

The article also makes a fundamental point.

When you need a new UI element, just because an existing component looks similar does not mean it’s appropriate. It’s tempting to think that way—especially when you prioritise reusability—however on the web the way something looks is only part of the story.

A well-built component that was made to handle whatever is thrown at it will convey meaning and purpose at a lower-level than the visual (CSS) level, so that it is understandable in both non-visual and visual environments.

That’s why sometimes the existing component is not a good fit because the purpose of the new thing, and the user’s intent when using it, are different to that of the existing thing. And bloating the existing component to change or muddy its purpose is bad for maintainability and reusability.

I loved this nugget on shifting left during design:

One of the things I’ve really pushed for in the most recent features is UX accessibility documentation during the design phase. What does that mean? Well, it means that when we are designing a new feature, we request that our UX designers and architects chat with our developers early and draft a basic semantic HTML structure and any specific accessibility behaviours. Think landmarks, headings, buttons, links, and careful focus management, to name a small selection.

I did this recently when working on a Data Table component with Zita. We found that early discovery of user intent allied to coding early semantic markup prototypes really informed our understanding of constraints, opportunities and architecture for the remainder of the process.

Additionally, this is great advice for comparing and choosing between components:

Focus on what components achieve rather than their appearance

To me this also highlights one of the key benefits of modern micro-layouts. Separate the content (and purpose) from the layout…then you get maximum reusability from those common, workhorse layouts because they are meaning-agnostic.

Mark Root-Wiley explains why navigation menus that appear on click rather than hover are better.

I like the fact that it calls out that:

When you first make this change, it’s true that some visitors might still expect hover menus. They may even say they prefer them if you ask.

But then goes on to provide some rationale (ammunition?) from various big guns on why click menus are better.

From the US Web Design System:

Avoid using hover to expand dropdown lists. Hover is difficult for some users and won’t work on touch screens. Dropdowns should expand on click or with keyboard navigation.

From popular frontend framework Bootstrap:

What it really boils down to is user intent. The purpose of a hover state is to indicate something is clickable (underlined text). The purpose of a click is to actually do something, to take an explicit action. Opening a dropdown is an explicit action and should only happen on click.

(via @jamesmockett)

I picked up a good accessibility testing tip from my work colleague Max today.

On a Mac, if you open System > Accessibility > Zoom, you can enable “hover text”. This allows you to hold down command (cmd) and then whatever is under the mouse will be shown. This shows the same text that a screen reader sees so it’s good for checking if bits of the page respond to a screen reader.

Jeremy Keith takes us through his thought process regarding the choice of link or button when planning accessible interactive disclosure elements.

A button is generally a solid choice as it’s built for general interactivity and carries the expectation that when activated, something somewhere happens. However in some cases a link might be appropriate, for example when the trigger and target content are relatively far apart in the DOM and we feel the need move the user to the target / give it focus.

For a typical disclosure pattern where some content is shown/hidden by an adjacent trigger, a button suits perfectly. The DOM elements are right next to each other and flow into each other so there’s no need to move or focus anything.

However in the case of a log-in link in a navigation menu which—when enhanced by JavaScript—opens a log-in form inside a modal dialogue, a link might be better. In this case you might use an anchor with a fragment identifier (<a href="#login-modal">Log in</a>) pointing to a login-form far away at the bottom of the page. This simple baseline will work if JavaScript is unavailable or fails, however when JavaScript is available we can intercept the link’s default behaviour and enhance things. Furthermore because the expectation with links is that you’ll go somewhere and modal dialogues are kinda like faux pages, the link feels appropriate.

While not explicit in the article, another thing I take from this is that by structuring your no-JavaScript experience well, this will help you make appropriate decisions when considering the with-JavaScript experience. There’s a kind of virtuous circle there.

Over the last couple of days I’ve witnessed a good example of progressive enhancement “In Real Life”. And I think it’s good to log and share these validations of web development best practices when they happen so that their benefits can be seen as real rather than theoretical.

A few days ago I noticed that the search function on my website wasn’t working optimally. As usual, I’d click the navigation link “Search” then some JavaScript would reveal a search input and set keyboard focus to it, prompting me to enter a search term. Normally, the JavaScript would then “look ahead” as I type characters, searching the website for matching content and presenting (directly underneath) a list of search result links to choose from.

The problem was that although the search input was appearing, the search result suggestions were no longer appearing as I typed.

Fortunately, back when I built the feature I had just read Phil Hawksworth’s Adding Search to a Jamstack site which begins by creating a non-JavaScript baseline using a standard form which submits to Google Search (scoped to your website), passing as search query the search term you just typed. This is how I built mine, too.

So, just yesterday at work I was reviewing a PR which prompted me to search for a specific article on my website by using the term “aria-label”. And although the enhanced search wasn’t working, the baseline search functionally was there to deliver me to a Google search result page (site:https://fuzzylogic.me/ aria-label) with the exact article I needed appearing top of the search results. Not a rolls-royce experience, but perfectly serviceable!

Why had the enhanced search solution failed? It was because the .json file which is the data source for the lookahead search had at some point allowed in a weird character and become malformed. And although the site’s JS was otherwise fine, this malformed data file was preventing the enhanced search from working.

JavaScript is brittle and fails for many reasons and in many ways, making it different from the rest of the stack. Added to that there’s the “unavailable until loaded” aspect, or as Jake Archibald put it:

all your users are non-JS while they’re downloading your JS.

The best practices that we as web developers have built up for years are not just theoretical. Go watch a screen reader user browse the web if you want proof that providing descriptive link text rather than “click here”, or employing headings and good document structure, or describing images properly with alt attributes are worthwhile endeavours. Those users depend on those good practices.

Likewise, JavaScript will fail to be available on ocassion, so building a baseline no-JS solution will ensure that when it does, the show still goes on.

A tool for testing how accessible your experience is on various assistive technologies – perhaps “like BrowserStack but for screen readers”?

Assistiv Labs remotely connects you to real assistive technologies, like NVDA, VoiceOver, and TalkBack, using any modern web browser.

I use a Mac for development which means that when I do screen reader testing I use the Mac’s VoiceOver tool. However the majority of screen reader users are using NVDA via Firefox on a PC. Perhaps this tool might let me test on that stack without buying a PC.

Next action: sign up for a free trial and give it a go!

(via Matthew and @paddyduke)

Strong agree with these sentiments regarding accessibility expressed by Max Böck and Andrey Okonetchnikov on Twitter.

From Andrey:

If you’re building UI, it’s your responsibility to make it work for everyone. Clients often tell me “we don’t care about accessibility” but in reality they do want keyboard support at the very least. So I just build my UI in a way it works without discussing it. It’s my job.

To which Max replies:

This. A11y is not “extra effort for people with disabilities”, it‘s just part of a well-crafted UI.

Here are five bite-sized and practical chunks of advice for creating accessible forms.

1. Always label your inputs.
2. Highlight input elements on focus.
3. Break long forms into smaller sections/pages.
4. Provide error messages (rather than just colour-based indicators)
5. Avoid horizontal layout forms unless necessary.

I already apply some of these principles, but even within those I found some interesting takeaways. For example, the article advises that when labelling your inputs it’s better not to nest the input within a <label> because some assistive technologies (such as Dragon NaturallySpeaking) don’t support it.

I particularly like the idea of using CSS to make the input which has focus more obvious than it would be by relying solely on the text cursor (or caret).

input:focus {
  outline: 2px solid royalblue;
  box-shadow: 1px 1px 8px 1px royalblue;
}

(via @adactio)

Hidde de Vries explains why an HTML heading should never be immediately followed by another.

When you use a heading element, you set the expectation of content.

I have always prided myself on using appropriate, semantic HTML, however it’s recently become clear to me that there’s one thing I occasionally do wrongly. Sometimes I follow a page’s title (usually an h1 element) with a subtitle which I mark up as an h2. I considered this the right element for the job and my choice had nothing to do with aesthetics.

However a recent article on subtitles by Chris Ferdinandi and now this article by Hidde have made me reconsider.

HTML headings are essentially ”names for content sections”. On screen readers they operate like a Table of Contents – one can use them to navigate to content.

Therefore I now reckon I should only use a hx heading when it will be immediately followed by (non-heading) content – paragraphs and so on – otherwise I should choose a different element.

I should probably mark up my subtitles as paragraphs.