Design Lance

• A guide to designing accessible, WCAG-compliant focus indicators — Sara Soueidan says you can make more accessible focus outlines by doing your own, rather than leaving it to the browser — as long as you do it right. Deep dive!
• a11y-syntax-highlighting — Eric Bailey’s repo of code syntax highlighting themes for a variety of software that are both attractive and meet WCAG color contrast guidelines (including support for Windows High Contrast mode as well).
• Respecting Users’ Motion Preferences — Michelle Barker with a guide on when and how to honor people’s prefers-reduced-motion setting. While there is no one right way, it should be done. It’s interesting how many things might apply. Properties like transition and animation are fairly obvious, but did you think of scroll-behavior or things specifically in JavaScript (where you can also test for a preference)?
• Accessibility testing — Jeremy Keith: “When you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.” Don’t waste an accessibility expert’s time telling you about color contrast problems because you can find and fix those yourself fairly easily.
• The effect of CSS on screen readers — Part of me wishes the effect of CSS on screen readers was “nothing” but Jozsef Polgar notes there are some things CSS does affect. A classic is setting list-style: none on lists will force them to not read as lists in VoiceOver. Jozsef points to Ben Meyer’s article covering similar ground.
• In Quest of Search — Sara again, this time weighing in on <search>. I’ve heard mostly negative things (like, why the focus on this when there are so many bigger fish to fry, like <dialog> and inert), but Sara is all for it. I agree that we might as well have an element that gives us a free role="search" like we get with <nav> and <main>.
• Accessible Palette: stop using HSL for color systems — Eugene Fedorenko says, “While HSL and HSV are fine choices for choosing a single color, they’re not suitable for building a color system, as they simply transform the RGB model and ignore the complexities of human perception.” It seems like everyone who has looked into next-gen color formats is a fan, but I haven’t wrapped my mind around them yet. Things like LCh, Lch(ab), HCL, LCH(uv)… There is starting to be some trickles of browser support.
• One last time: custom styling radio buttons and checkboxes — Scott O’Hara notes that you can entirely replace these inputs with custom styling, and do it accessibly. Part of doing it right is dealing with every possible state. Worth noting: without replacing everything, you can get pretty far in styling checkboxes/radios by just changing width/height and the accent-color, as Dave and I noted here.
• Understanding Logical Focus Order — Rachel Leggett explains it is “the idea that someone navigating your webpage with a keyboard (i.e. without a mouse) will encounter elements in an order that makes sense.” Nearly anytime you use the order property, you’re probably interferring here. But less obviously, hidden elements that remain interactive can confuse logical focus order.
• Assistiv Labs — I didn’t realize there was a tool in the vein of CrossBrowserTesting or BrowserStack that allowed you to test in JAWS and NVDA and stuff — but there is! Just the other day I wanted to test in JAWS, so I spun up a (paid) copy of Parallels with my (paid) copy of Windows 10 and used my (40-minute test version) of JAWS to test. While it worked, it was not particularly cheap or without significant technical debt. This seems easier, although I haven’t actually tried it yet.

The post Some Articles About Accessibility I’ve Saved Recently IV appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

• The perfect link — Rian Rietveld defines them: “When you click on them, they take you somewhere else.” Not much code in here (we’ve got that), just a lot of practical accessibility advice. For example, the alt text for a linked image can allude to the fact that it is a link. Just an image: “A cherry tree in full bloom.” Link: “Wikipedia on cherry blossoms.”
• Google Announces Seismic Change to Docs — George Joeckel covers the unfolding news that Google Docs is going to be rendered in <canvas>, which feels like a massive WTF moment when it comes to accessibility. At one point, the vibe was that there would be a separate product for people with screen reader needs. Separate but equal isn’t a good situation. Looks like the <canvas> based rendering stuff is on hold for now, so community feedback FTW?
• Don’t use custom CSS mouse cursors — Eric Bailey: I believe that letting CSS load a custom cursor was a mistake.
• Web Designers Grapple With Downside to Flashy Animation: Motion Sickness — Katie Deighton covers the idea that things like preference toggles and prefers-reduced-motion exists (although not by name). Always interesting to see a topic like this makes its way to a major publication like The Wall Street Journal.
• prefers-reduced-motion and browser defaults — Speaking of prefers-reduced-motion, Bruce Lawson on the paragraph-of-the-year: Yes, it was a meeting request from Marketing to discuss a new product page with animations that are triggered on scroll. Much as a priest grasps his crucifix when facing a vampire, I immediately reached for Intersection Observer to avoid the browser grinding to a halt when watching to see if something is scrolled into view. And, like an exoricst sprinkling holy water on a demon, I also cleansed the code with a prefers-reduced-motion media query.
• Using CSS to Enforce Accessibility — Adrian Roselli covers this great tactic where you don’t get the proper CSS styling unless you’ve also implemented the appropriate accessibility attributes (e.g. [role="region"][aria-labelledby][tabindex] for a scrolling table). This is a powerful idea and happens to showcase the power of CSS nicely in a way that styling solutions that avoid using selectors don’t benefit from.
• Accessibility testing with Storybook — Varun Vachhar covers how you can run Axe over your component library even as you code. Accessibility issues, like color contrast problems, are bugs. Might as well give yourself the same tooling opportunities to fix them at the same time you’d fix any other bug.
• Making A Strong Case For Accessibility — Todd Libby covers how you can fight for accessibility at work. Attempt 1.) Ethical. Attempt 2.) Financial. Attempt 3.) Legal. 4.) Humanization. Attempt 5.) Don’t ask, just do it.
• Your Image Is Probably Not Decorative — Eric Bailey covers that most images with an empty alt attribute (literally alt="", no space) probably should have had one, and that when and alt description isn’t available, there are other options (e.g. make it available as an inline image (spacer.gif) even if it isn’t one otherwise, <title> in SVG, etc.).
• Writing great alt text: Emotion matters — Annnnd speaking of alt, Jake Archibald learns from a 2011 Léonie Watson article: The relevant parts of an image aren’t limited to the cold hard facts.

• Creating An Accessible Dialog From Scratch — Kitty Giraudel takes on the final boss in accessibility.

The post Some Articles About Accessibility I’ve Saved Recently III appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

• “Good news about display: contents and Chrome” — Rachel Andrew notes that the accessibility danger of using display: contents; is fixed in Chrome. The problem was that, say you had a parent div that is laid out as a grid and inside you have a <ul> with <li> elements, and you wanted the <li> elements to participate on that same parent grid. We have subgrid, but it’s not really the same thing. What you want is just to pretend like the <ul> isn’t there at all and that the <li> elements can hang out on the grid like anything else. The problem was that if you did that, you wiped out the accessible semantics of the list. But no more!
• “Grid, content re-ordering, and accessibility”  — Speaking of grids and accessibility, here’s Rachel again teaching us (through this slide deck) how it’s all-too-easy to really diverge the source order and display order of content with modern layout techniques. At the moment, the solution is essentially not to do that, but the future might hold a way for browsers to update tab order to be visually sensible when you do dramatically alter the layout.
• “The most useful accessibility testing tools and techniques” — Atrem Sapegin lists out some good ones, like eslint-plugin-jsx-a11y, storybook-addon-a11y, cypress-axe, Contrast app, Spectrum browser extension, and… using your tab key (lolz).
• ButtonBuddy — Tool from Stephanie Eckles that helps generate CSS for buttons. But the real point of it is to give you colors as custom properties that satisfy color contrast guidelines.
• “Are your Anchor Links Accessible?” — Amber Wilson goes through five iterations of an anchor link in/by a header before landing on a good one and, even then, there are questions to tackle.
• “Don’t put pointer-events: none on form labels” — I’m a little shocked that anyone would do this at all, but it turns out it comes from Material Design’s “floating label” pattern. I think that pattern is so silly. It doesn’t actually save any space because you need the space where you float the label to anyway. Gosh.
• “Accessible Text Labels For All” — Sara Soueidan tests real accessibility software and how it presents common interactive elements. For example, a “read more” link isn’t very useful (read more what?), and “add to cart” isn’t very useful alone (add what to cart?). You can add, for example, product names to those “add to cart” buttons, but don’t do it in the middle of the button as that can break things. Add the extra text at the end.

The post Some Articles About Accessibility I’ve Saved Recently appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks