Five years ago I wrote about The Accessibility Project (a.k.a. the A11y Project) on this blog as it has long been a useful resource for learning about accessibility. In July of this year, a new site redesign launched showcasing the talents of designer Tatiana Mac and the A11yProject community. It's a beautiful and highly functional site well-deserving of an Accessibility Win!

I love the bold colors, big readable fonts, and information architecture. It's got a skip link, innovative focus styles, and a meaningful banner supporting Black Disabled people and the Black Lives Matter movement. The site communicates what's most important and I really love that.

Recently, Adobe launched their Spectrum design system complete with an open-source implementation, Spectrum CSS. In addition to an extremely polished and well thought-out presentation, Spectrum’s focus on accessible CSS practices and quality markup is a breath of fresh air. Its use is likely to facilitate more accessible websites and applications, which is fantastic.

Spectrum the design system includes principles, pattern guidelines, content recommendations, tools and resources, and more; not dissimilar from Google’s Material Design. The Spectrum CSS project, in contrast to its design system, is a working collection of component styles that you can download from npm or explore on GitHub and apply to your own project. It’s an incredible resource to have available, particularly with its rigorous testing and attention paid to accessibility.

One outstanding question I do have is about the textarea component, which doesn’t illustrate usage with a label element and could lead developers to omit a critical piece of accessibility information. But that’s more of an issue with docs/education than a shortcoming of the library, itself. Many of the patterns I reviewed included SVG and ARIA best practices, a welcome contribution in a world of DIV soup component libraries.

A project I've been recommending a lot lately is Accessibility Insights, a set of free testing tools from Microsoft. It uses axe-core under the hood (which I used to work on) and was years in the making. They're currently offering browser extensions for Chrome and Edge Insider, as well as a testing solution for Windows applications. Super cool!

There's a lot to love about Accessibility Insights for Chrome/Edge in particular, but I really love the tab order and headings tools. You can run automated scans for whole pages and dive deeper into ad-hoc tools, gaining knowledge about the health and quality of your pages (or the lack thereof). Microsoft did a lot of solid design and planning work along with their partnership with Deque, and it's been great to see this launch (even if I'm a few months late to write about it!).

I just love the personal site of Manuel Matuzović, a front-end developer based in Vienna, Austria. I was reading through Manuel’s slides for a talk he did at React Finland yesterday on 12 Tips for More Accessible React Apps and was immediately impressed with the bold design on his site (it looked great on mobile, and works wonderfully on desktop as well). Knowing his typical attention to detail for accessibility, I was pretty sure the site would be wonderfully accessible. And it is! 

I love the little touches with a skip link neatly nestled into the design, animated SVG logo on focus and various link interactions. Manuel used semantic markup in his pages, with a visually hidden h1 element with his name on the homepage. It’s a breath of fresh air getting to see a nicely designed site and know that it’s got accessibility handled! There’s a “beta” message on it, but I think it’s already in great shape.

Manuel: thank you for sharing your knowledge with us in your talks and content bits like the TIL (“Today I Learned”) section of the site. I especially love your Dark Side of the Grid stuff as I’m also using and speaking about accessible CSS Grid. Your contributions are fantastic and I hope they continue!

Have you ever heard someone say, "accessible websites are boring"? Hopefully you already know that is an incorrect sentiment, as accessible digital experiences can be beautiful, innovative, well designed and highly functional. With that said, I have a new example for you to hold up and shatter that assumption: the website of Tatiana Mac, an Art Director, Designer and Developer with a focus on inclusive design. She uses bold colors with a sophisticated aesthetic to express her personal brand, and she did a wonderful job making her website accessible.

Decent markup laid out with CSS Grid, little-to-no axe violations (short of one image missing alt text and a few best practices), great color contrast, and quite a bit of personality: those are the things I love about Tatiana's site. She could perhaps rearrange some headings and add a few more landmarks, but I think you'll find she paid a lot of respect towards accessibility in building her website. Her point of view and values shine through; in a world of endless inaccessible portfolio sites, this one explifies accessible web design done well. And it's so refreshing!

I've heard from colleagues and friends who rely on screen reading software that Facebook.com has historically presented challenges when consuming content. Something about the news feed having many sections and lots of dynamic content made it difficult to navigate. However, I was pleased to discover last week that Facebook has added an accessibility navbar, accessible with keyboard shortcuts (Alt + /) and as the first item in the tab order.

Having a global navigation bar for keyboard and screen reader users is fantastic. The entire navbar acts as one tab stop, with the arrow keys taking you through dropdown menus for sections, pages and accessibility help. When applicable, a visible outline shows the section or landmark targeted by a dropdown menu item. But the best part of this navbar? It extends landmark navigation to all keyboard users, not just those using assistive technologies.

As a web developer and person working on accessibility tools full time, this win provides a lot of satisfaction: Chrome Canary’s developer tools have an experiment where you can debug color contrast right in the style inspector. For a given foreground color, clicking on it in the inspector now shows how it relates to WCAG AA contrast ratios. You can also expand it to show the AAA ratio from inside the color picker.

By meeting these ratios, users with low vision or difficulty seeing color will have a higher likelihood of being able to use your sites! Color contrast is also the #1 accessibility fail on the web. So this tool is very close to my heart!

I was a little thrown off by inherited background colors at first; especially for user-agent styles like the default link color, where no color style is shown (but I'm an edge case weirdo–most people would provide a CSS color). The color picker shows a gradient of the two colors with the background indiciated as a circle icon; a visible hexadecimal or RGB value probably would have helped me understand it quicker. But there's also an interactive color picker you can change on the fly to adjust the ratio, which is a killer feature.

We do a lot of work to test color contrast in the axe-core library and browser extensions, and I know that it isn’t easy to deal with all the edge cases. But hopefully in a privileged browser context they can utilize processes for painting the screen according to CSS in a performant way. Chrome's contrast devtool will be a great complement to the aXe extensions, or aXe in Lighthouse.

There's a visually beautiful drag & drop solution making the rounds on the web, and it even touts itself as being "accessible". The problem is, you can't actually use it with the keyboard in its current iteration–a huge, blocking barrier to people who can't use the mouse. If you are looking to implement drag & drop on a website, I HIGHLY recommend checking out Dragon Drop by Harris Schneiderman.

Dragon Drop is available on Github and it's framework agnostic, so you could work it into a bigger project. To make it accessible, each movable object has a dragger button that can be moved with the keyboard once you enter edit mode with the space bar or enter key.

Here's an integral part of its accessibility: the button elements used for reordering are natively focusable, so keyboard and screen reader users can reach them. Disabled users can't magically start using the mouse to drag and drop, a strange expectation of many "accessible drag and drop" solutions (slapping ARIA attributes on it isn't enough!).

Harris did the work not only to make it keyboard operable, but also to pipe customizable screen reader messaging using ARIA Live Regions. He made sure it worked in major assistive technology/browser combos. Speaking from experience, it can be difficult to support Windows screen readers like JAWS when mouse interactions differ from the keyboard. This solution works around that with the edit mode and button accordances for manipulating items with the keyboard.

If you do find an issue with it, I'm sure he'd love to hear from you on Github!