Tag: Accessibility

Grid, content re-ordering and accessibility

Take this:

<ol>   <li>Get hungry</li>   <li>Order pizza</li>   <li>Eat pizza</li> </ol>

That HTML ends up in the DOM that way (and thus how it is is exposed to assistive technology), and by default, those list items are also visually shown in that order. In most layout situations, the visual order will match that DOM order. Do nothing, and the list items will flow in the block direction of the document. Apply flexbox, and it will flow in the inline direction of the document.

But flexbox and grid also allow you to muck it up. Now take this:

ol {    display: flex;   flex-direction: row-reverse; }

In this case, the DOM order still makes sense, but the visual order is all wrong. It’s not just row-reverse. There are a number of flexbox and grid properties that can get involved and confuse things: the order property, flowing items into columns instead of rows, and positioning items specifically in unusual orders, among others. Even absolute positioning could cause the same trouble.

Manuel Matuzovic says:

If the visual order and the DOM order don’t match, it can irritate and confuse users up to a point where the experience is so bad that the site is unusable.

Rachel Andrew highlights this issue (including things we’ve published) as a big issue, and hopes we can get tools at the CSS level to help.

I think this is something we sorely need to address at a CSS level. We need to provide a way to allow the tab and reading order to follow the visual order. Source order is a good default, if you are taking advantage of normal flow, a lot of the time following the source is exactly what you want. However not always, not at every breakpoint. If we don’t give people a solution for this, we will end up with a mess. We’ve given people these great tools, and now I feel as if I’m having to tell people not to use them.

Direct Link to ArticlePermalink

The post Grid, content re-ordering and accessibility appeared first on CSS-Tricks.


, , ,

Do you need an ICON ONLY button without screwing up the accessibility?

The first consideration is: do you really? If you can, having text next to your icons is proven over and over again to be the most accessible and clearest UX (see Apple’s latest blunder). But if you need to (and I get it, sometimes you need to), Sara Soueidan and Scott O’Hara have a pair of articles that nicely lay out all the options and present actual research on this topic.

If you just want to be told what to do, I’d go for the just use some text in the button approach:

<button aria-expanded="false" id="menu-trigger">    <svg viewBox="0 0 32 32" width="32px" height="32px"       aria-hidden="true" focusable="false">      <!-- svg content -->     </svg>     Menu </button>

Sara says There is no One Way to Rule Them All, but it does seem like you really need to use actual text inside that button and either hide it or override it somehow. SVG alone has no rock solid way to provide an accessible name to a button or link.

Funny how long this has been a tricky pattern to get right.

The post Do you need an ICON ONLY button without screwing up the accessibility? appeared first on CSS-Tricks.


, , , , , ,

Weekly Platform News: Favicon Guidelines, Accessibility Testing, Web Almanac

Šime posts regular content for web developers on webplatform.news.

Google posts guidelines for defining favicons

Jamie Leach: Google Search now displays favicons in search results on mobile. Your favicon should be a multiple of 48×48 (Google will re-scale it to 16×16 for use in search results). If a website doesn’t have a favicon or Google deems the favicon inappropriate, a generic globe icon will be displayed instead.

Your favicon should be a visual representation of your website’s brand, in order to help users quickly identify your site when they scan through search results.

Top websites are surprisingly inconsistent in the way they declare icons (via <link> elements in the page’s head). Twitter and Pinterest, two relatively modern progressive web apps, provide icons in two sizes.

<!-- example --> <link rel="icon" href="/icon-32x32.png"> <link rel="apple-touch-icon" href="/icon-192x192.png">

The Paciello Group releases ARC Toolkit

The Paciello Group: ARC Toolkit, our professional-level accessibility testing tool, is now available as a Chrome DevTools extension. This tool detects issues related to the WCAG 2.1 guidelines. You can run the test on the entire page or just the node selected in the DevTools Elements panel.

Remember, automated accessibility tools are only able to find some accessibility issues, and manual testing is necessary to ensure full accessibility. Lighthouse (via the Audits panel) suggests manual checks after performing an accessibility audit.

Other news

  • Jeff Jaffe: W3C and WHATWG have reached an agreement to collaborate on the development of HTML. “W3C shall encourage the community … to contribute directly to the WHATWG HTML and DOM repositories; raising issues, proposing solutions, commenting on proposed solutions, and indicating support or otherwise for proposals.”
  • Paul Calvano: “There is a significant gap in the first- vs. third-party resource age of CSS and web fonts. 95% of first-party fonts are older than one week compared to 50% of third-party fonts … This makes a strong case for self-hosting web fonts!”
  • Rachel Andrew: The CSS subgrid value is a relatively straightforward addition to grid layout. For example, if you have nested grids, and you apply grid-template-rows: subgrid to the child grid, then this grid will use the row tracks of the parent grid instead of creating its own row tracks. That’s all there is to it. (This feature is currently only supported in Firefox Nightly.)
  • GitHub Blog: GitHub can now generate automated security fixes for your dependencies with known security vulnerabilities. On GitHub’s website, check your repository’s Security tab for security alerts. If you open an alert and press the “Create automated security fix” button, GitHub will create an automated pull request that fixes the security vulnerability.
  • Rick Viscomi: HTTP Archive plans to release the first annual Web Almanac in November, a report of the state of the web with interesting insights written by different experts. About 50 volunteers from the web community are currently working on it, and they are looking for more contributors.

The post Weekly Platform News: Favicon Guidelines, Accessibility Testing, Web Almanac appeared first on CSS-Tricks.


, , , , , , ,

Color contrast accessibility tools

Accessibility is all the rage these days, specifically when it comes to color contrast. I’ve stumbled upon a couple of tools this week that I think are pretty nifty for helping make sure that all of the text on our websites is legible regardless of what background color they might have.

First up is the Accessible Color Generator which happens to be a wonderful tool for picking alternative colors. Let’s say you’re working on a brand with color X. You can generate a host of other complimentary colors like this:

Next up is Contrast, a rather great MacOS app that sits in the menu bar at all times and helps identify accessible color pairings based on WCAG Guidelines. This one is particularly useful if you happen to be a designer:

This reminds me of a wonderful post about how the Lyft design team re-approached the way they use color in their app. Kevyn Arnott explains:

Color, at least on the surface, appears almost naively simple, yet as it scales across larger products it becomes unbelievably complex. You have thousands of people building products all at once, and those products are all heavily reliant on color. This puts a lot of pressure on the color system to ensure that all the products are being created consistently, but very hard to implement since it’s all too easy to apply colors on a one-off basis.

The team then went ahead and built ColorBox.io which lets you systematically build out a ton of colors for your design systems work. It’s pretty nifty!

Plus the folks over at GOV.UK made their own color accessibility tool called Contrast Checker which (as you have guessed by the name) helps check the contrast between the background of an element and the page itself:

And, of course, there’s the trusty WebAIM contrast checker, which is a go-to for many developers out there.

So far, we’ve looked at tools that check contrast. But there is a class of tooling that can automate accessible contrasts during development. Josh Bader wrote up an approach that enforces high contrast by pairing CSS custom properties with the calc() function. Facundo Corradini did something similar that switches font color based on the background color behind it.

Oh! And we may have something to look forward to with the color-adjust property. It is proposed in the CSS Color Module Level 4 specification and could give browsers more control to adjust color values that are declared in the stylesheet. It’s not really geared towards color contrast, but there’s something interesting about handing off the responsibility of rendering color values to the browser based on certain conditions.

The post Color contrast accessibility tools appeared first on CSS-Tricks.


, , ,

Naming things to improve accessibility

I like the this wrap-up statement from Hidde de Vries:

In modern browsers, our markup becomes an accessibility tree that ultimately informs what our interface looks like to assistive technologies. It doesn’t matter as much whether you’ve written this markup:

  • in a .html file
  • in Twig, Handlebars or Nunjucks
  • as the <template> in a Vue Single File Component
  • exported in the JSX of your React component
  • outputted by a weird legacy CMS

It is which markup that determines if your site is pleasurable to experience for AT users. In short: it’s the markup that matters

As a front-end developer, you’ll find yourself writing markup in lots of different places with lots of different technologies. I think it behooves you think of how best to write it regardless of where and how.

Direct Link to ArticlePermalink

The post Naming things to improve accessibility appeared first on CSS-Tricks.


, , ,

Accessibility Events

“There isn’t some way to know when—…?”

There is always a pause here. The client knows what they’re asking, and I know what they’re asking, but putting it into words—saying it out loud—turns unexpectedly difficult.

In the moments before the asking, it was a purely technical question—no different from “can we do this when a user is on their phone.” But there’s always a pause, because this question doesn’t come easy; not like all the other questions about browsers and connection speeds did. A phrase like “in an assisted browsing context” doesn’t spring to mind as readily as “on a phone,” “in Internet Explorer,” or “on a slow connection.” The former, well, that’s something I would say—a phrase squarely in the realm of accessibility consultants. The latter the client can relate to. They have a phone, they’ve used other browsers, they’ve been stuck with slow internet connections.

“There isn’t some way to know when—… a user is… using something like a screen reader…?”

An easy question that begets a complicated answer is standard fare for almost any exchange with a web developer. This answer has, for a long time, been a refreshing deviation from that norm: “no, we can’t.”

The matter is, I’ll offer, technically impossible; computers, you see, can’t talk to each other that way. Often, there’s a palpable relief here: “no” to the technical part; “no” to the the computers part. That is, of course, all they had meant to ask. I truly believe that.

Even if we could, I’ll explain, we wouldn’t really want to. Forking our codebase that way would put more burden on us maintainers, not less. There’s an easy parallel to the “when they’re on a phone” conversation, here; one we’ve surely had already. We can never know a user’s browsing context for certain, and making assumptions will only get us and our users into trouble. Whenever a feature, component, or new design treatment was added or changed, we’d be left having all the same conversations around how to translate it over to the “accessible” experience. If those features aren’t essential in the first place, well, are they worth having at all? If those features are essential—well, we’ll still need to find a way to make them work in both contexts.

It could seem like an enticing option for our users, at first glance: an enhanced, fully-featured website, on the one hand, a fully accessible alternative experience on the other. That unravels with even the slightest examination, though: if the fully-featured website isn’t accessible, the accessible website won’t be fully featured. By choosing to have the “accessible experience” deviate from the “real website,” we end up drawing a sharper line between those two definitions, and we nudge the “accessible experience” closer to an afterthought—limited and frustratingly out-of-sync with the “real” website, like so many dedicated mobile sites quickly became.

There’s never any disagreement, here. Again: this is all relatable. We’ve all found ourselves inescapably opted into using the “mobile” version of a website at some point. We’ve been here before as users; we’ve made these mistakes before as developers. We know better now.

But this isn’t a strictly technical question. This isn’t as simple as browser features and screen sizes—a question of one privileged browsing context or another. Technical questions come easy. Partway through the asking—in the hesitation, in the pause, in the word stumbled over—what was meant to be a mundane development question became something much more fraught. Because there was a word that fit.

“Is there a way we can know when a user has a disability?”

The easy “no” felt empowering; a cop-out. “It doesn’t matter; it can’t be done” in response to a deeply fraught question was an unexpected balm for both the asked and the answered. There was, again, that palpable relief—”no” to the technical part; “no” to the the computers part. That was, of course, all they had meant to ask.

We no longer have that easy answer. In iOS 12.2 and MacOS 10.14.4, a toggle switch has appeared in Apple’s VoiceOver preferences, innocuously labeled “accessibility events.” It was rolled out to no fanfare—short of a brief mention in Apple’s iPhone User Guide—and we’re still not sure how it’s meant to be used. The most generous interpretation of the intention behind this feature is that it was developed with the same intention as a “UA string”-style identifier for users browsing via VoiceOver.

We do know this much: when this setting is enabled—and it is, by default—your browser will identify you as using VoiceOver to help you browse the web. If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.

If you’re not furious at this change, you should be—not just for what it means for users, but what it foists upon you. Apple has burdened you with the knowledge that, now, yes, you can know whether a user has a disability. We can use this information to serve up a limited alternative version of a website, into which we can very easily opt people of a protected class. And once we choose to start listening for “accessibility events,” well, we can capture that information, as anything else broadcast to the web. A user’s disability can and will be reduced to a single data point—a cold, impersonal true, inexorably bound to their name, stored in a database, perhaps destined to be sold, leaked, passed along to insurance providers, reduced to a targeted marketing opportunity. All under the auspice of inclusivity.

At some point, the developers responsible for the “accessibility events” feature were, I’m certain, asked whether such a feature were possible. Their answer was “yes.” I don’t doubt that they meant well. I’m just as certain that, in the moment, it felt like the right answer; a technical solution to a technical problem, and a simple matter of browsing context.

Someday—not far in the future, I trust—I’ll be asked a similar question. It will be asked hesitantly, haltingly. The pauses will ring all too familiar. I will no longer have the easy, familiar comfort of technical impossibility—no easy “no” to insulate me from the uncomfortable conversations I should have been having with clients all along. Now, there’s no technical reason that I can’t know whether a user is using “something like a screen reader.” I—my clients, their databases, their organizations, their parent companies, their partners, their VC funders, their advertisers, and so on unto infinity—can absolutely know when a user is disabled.

But I won’t play a part in helping to propagate the mistake Apple’s developers made. I’ll let my answer hang heavy and uncomfortable in the air: no. Not because we can’t—we can. Not because we shouldn’t, though, no, we still shouldn’t. No—now, I will allow the word to become as coarse as I had always wanted it to be, because I no longer have the cold comfort of “well, technically” to hide behind.



The post Accessibility Events appeared first on CSS-Tricks.



Some Notes About Accessibility

Earlier this month Eric Bailey wrote about the current state of accessibility on the web and why it felt like fighting an uphill battle:

As someone with a good deal of interest in the digital accessibility space, I follow WebAIM’s work closely. Their survey results are priceless insights into how disabled people actually use the web, so when the organization speaks with authority on a subject, I listen.

WebAIM’s accessibility analysis of the top 1,000,000 homepages was released to the public on February 27, 2019. I’ve had a few days to process it, and frankly, it’s left me feeling pretty depressed. In a sea of already demoralizing findings, probably the most notable one is that pages containing ARIA—a specialized language intended to aid accessibility—are actually more likely to have accessibility issues.

Following up from that post, Ethan Marcotte jotted down his thoughts on the matter and about who has the responsibility to fix these issues in the long run:

Organizations like WebAIM have, alongside countless other non-profits and accessibility advocates, been showing us how we could make the web live up to its promise as a truly universal medium, one that could be accessed by anyone, anywhere, regardless of ability or need. And we failed.

I say we quite deliberately. This is on us: on you, and on me. And, look, I realize it may sting to read that. Hell, my work is constantly done under deadline, the way I work seems to change every year month, and it can feel hard to find the time to learn more about accessibility. And maybe you feel the same way. But the fact remains that we’ve created a web that’s actively excluding people, and at a vast, terrible scale. We need to meditate on that.

I suppose the lesson I’m taking from this is, well, we need to much, much more than meditating. I agree with Marcy Sutton: accessibility is a civil right, full stop. Improving the state of accessibility on the web is work we have to support. The alternative isn’t an option. Leaving the web in its current state isn’t fair. It isn’t just.

I entirely agree with Ethan here – we all have a responsibility to make the web a better place for everyone and especially when it comes to accessibility where the bar is so very low for us now. This isn’t to say that I know best, because there’s been plenty of times when I’ve dropped the ball when I’m designing something for the web.

What can we do to tackle the widespread issue surrounding web accessibility?

Well, as Eric mentions in his post, it’s first and foremost a problem of education and he points to Firefox and their great accessibility inspector as a tool to help us see and understand accessibility principles in action:

An image of the Firefox Accessibility tool inspecting the CSS-Tricks website

Marco Zehe is on the Firefox accessibility team wrote and about what the inspector is and how to use it:

This inspector is not meant as an evaluation tool. It is an inspection tool. So it will not give you hints about low contrast ratios, or other things that would tell you whether your site is WCAG compliant. It helps you inspect your code, helps you understand how your web site is translated into objects for assistive technologies.

Chris also wrote up some of his thoughts a short while ago, including other accessibility testing tools and checklists that can help us get started making more accessible experiences. The important thing to note here is that these tools need to be embedded within our process for web design if they’re going to solve these issues.

We can’t simply blame our tools.

I know the current state of web accessbility is pretty bad and that there’s an enormous amount of work to do for us all, but to be honest, I can’t help but feel a little optimistic. For the first time in my career, I’ve had designers and engineers alike approach me excitedly about accessibility. Each year, there are tons of workshops, articles, meetups, and talks (and I particularly like this talk by Laura Carvajal) on the matter meaning there’s a growing source of referential content that can teach us to be better.

And I can’t help but think that all of these conversations are a good sign – but now it’s up to us to do the work.

The post Some Notes About Accessibility appeared first on CSS-Tricks.


, , ,

See No Evil: Hidden Content and Accessibility

There is no one true way to hide something on the web. Nor should there be, because hiding is too vague. Are you hiding visually or temporarily (like a user menu), but the content should still be accessible? Are you hiding it from assistive tech on purpose? Are you showing it to assistive tech only? Are you hiding it at certain screen sizes or other scenarios? Or are you just plain hiding it from everyone all the time?

Paul Hebert digs into these scenarios. We’ve done a video on this subject as well.

Feels like many CSS properties play some role in hiding or revealing content: display, position, overflow, opacity, visibility, clip-path

Direct Link to ArticlePermalink

The post See No Evil: Hidden Content and Accessibility appeared first on CSS-Tricks.


, , ,

Accessibility is not a “React Problem”

Leslie Cohn-Wein’s main point:

While [lots of divs, inline styles, focus management problems] are valid concerns, it should be noted that nothing in React prevents us from building accessible web apps.

True. I’m quite capable (and sadly, guilty) of building inaccessible interfaces with React or without.

I’ve long told people that one way to level up your front-end design and development skills, especially in your early days, is to understand how to change classes. I can write a few lines of JavaScript to add/remove an active class and build a tabbed interface quite quickly. But did I build the HTML in such a way that it’s accessible by default? Did I deal with keyboard events? Did I deal with all the relevant aria-* attributes? I’ll answer for myself here: no. I’ve gotten better about it over time, but sadly my muscle memory for the correct pattern isn’t always there.

I also tend to listen when folks I trust who specialize in accessibility say that the proliferation of SPAs, of which React is a major player, conspicuously coincides with a proliferation of accessibility issues.

I’m optimistic though. For example, React has a blessed tabs solution that is accessible out of the box. I reach for those, and thus my muscle memory for building tabs now results in a more accessible product. And when I to routing/linking with Reach Router, I get accessibility “baked in,” as they say. That’s a powerful thing to get “for free,” again, as they say.

Direct Link to ArticlePermalink

The post Accessibility is not a “React Problem” appeared first on CSS-Tricks.


, ,

Too Much Accessibility

I like to blog little veins of thought as I see them. We recently linked to an article by Facundo Corradini calling out a tweet of ours where we used an <em> where we probably should have used an <i>.

Bruce Lawson checks if screen readers are the victims of these semantic mistakes…

Whenever I read “some browsers” or “some screenreaders”, I always ask “but which ones?”, as did Ilya Streltsyn, who asked me “what is the current state of the text-level semantics in HTML reality?”

Léonie Watson to the rescue! Over Twitter, Watters wrote

Most are capable of reporting these things on demand, but do not as standard. So you don’t hear the text/font characteristics being announced as you read, but you can query a character/word etc. to discover its characteristics. This is based on the visual presentation of the text though, rather than through any recognition of the elements themselves

Which I suppose is to say that if you’re really fretting about screen readers misinterpreting the nuanced usage of your semantic emphasis… you can relax on that one.

Bruce’s article led me toward Steve Faulkner’s article “Screen Readers lack emphasis” from 2008.

Using the semantic elements strong and em does not convey any useful information to users of JAWS or Window Eyes under typical browsing conditions. While it is good to know this, it is not a reason to not use these elements to convey meaning. Accessibility is not just about people with vision impairment, it’s about all user’s with disabilities, and web standards is not just about accessibility.

So, not much has changed there in a decade. It’s unclear to me if things should change here or not, but if virtual voices are improving, it stands to reason they could get better at voice inflections that convey emphasis. I certainly am thinking of voice emphasis when I write those HTML tags.

This idea of too much accessibility has been a bit of a theme.

Please don’t read this article as suggesting that we worry too much about accessibility — only that it’s possible to worry about the wrong things and even screw up accessibility in the process, just like anything else.

The post Too Much Accessibility appeared first on CSS-Tricks.