Skip to content

#StateOfA11y - Why A11y is so important

🤔 What is accessibility and what does it mean on the web?

How can we improve accessibility within our websites?

Is accessibility something we can overlook or put on the back burner?

If you’ve been curious about what accessibility is and how it plays a role on the web, this talk will definitely be one to watch. In this article, I will talk about the key points and takeaways from the #StateOfA11y event hosted by Rob Ocel and Dacey Nolan.

Before we get started, let’s take a look at our panelists!

Stateofa11y screenshot


Rob Ocel @robocell
  • Team Lead and Software Architect, This Dot Labs
Dacey Nolan @dacey_nolan
  • Software Engineer, Trainual


Marcy Sutton @marcysutton
  • Owner and Lead Engineer, Modern Sole Design
Tim Winfred @Contimporary
  • Front-End & JavaScript Web Developer, Curative
Anna E. Cook @annaecook
  • Senior Accessibility Designer, Northwestern Mutual
Carie Fisher @cariefisher
  • Sr. Accessibility Consultant and Trainer, Deque
Nicolas Steenhout @vavroom
  • Independent Accessibility Consultant
Crystal Preston-Watson @ScopicEngineer
  • Quality & Accessibility Engineer, Salesforce

🔑 Key Takeaways

  • UX promotes effective accessibility. If the UX is poor and fails to deliver on key points, accessibility will also suffer.

  • Want to become effective at writing accessible code? Try going to your favourite websites and using your keyboard to navigate! Once you're familiar with how it works, you can improve your code in accessibility!

  • How does the increase in remote work affect accessibility? Introducing more people to websites and applications to help facilitate effective communication and work.

  • Accessibility exists in many forms and exists beyond the web in more ways than one

  • How do we get better at onboarding ourselves and others into building better accessibility? Documentation.

  • The future of accessibility is: choice. Dark mode, enlarged text, animations. Having a single source of truth is the future!

  • Want to be effective at writing accessible code? Bring it back to the basics! Learn how to write proper HTML!

💭 Have any questions or points to share? Use #StateOfA11y on Twitter and talk with us!

📺 View the replay here for fun stories, great tips, and faces to names! 🤝

This Dot Labs is a development consultancy that is trusted by top industry companies, including Stripe, Xero, Wikimedia, Docusign, and Twilio. This Dot takes a hands-on approach by providing tailored development strategies to help you approach your most pressing challenges with clarity and confidence. Whether it's bridging the gap between business and technology or modernizing legacy systems, you’ll find a breadth of experience and knowledge you need. Check out how This Dot Labs can empower your tech journey.

You might also like

Make it Accessible: Accessible Alphabet Board with Angular and RxJs cover image

Make it Accessible: Accessible Alphabet Board with Angular and RxJs

Alphabet Board in Angular Intro I've seen Breaking Bad so many times. Like honestly at least 4 times. If you haven't seen it, be careful, it will keep you in front of the TV for several days. In a nutshell, the show is about a high school teacher, named Walter, who gets diagnosed with cancer, and decides to cook meth to pay for his medical bills. Over the course of the show, Walter goes through some extreme lengths to hide his criminal activity- the first time you see it, you think he is so smart! When you get to see it as many times as I have, you notice that he is not only smart, but extremely lucky. There's another character, Hector Salamanca. He is a former high profile drug runner, and patriarch to a criminal family that is competing for territory with Walter. Since his more involved criminal days, he has had a severe stroke, and communicates with nothing but a bell. If you have seen the show, you should remember him. If not, you can imagine how frustrating it must be to not be able to communicate with verbal or written language. Salamanca, however, is able to better communicate with the help of his nephews, who are always there for him. I've been working with accessibility for a few weeks now, and it has totally shifted the way I do things. So when I saw Breaking Bad the last time, I was really interested in finding out a way that the characters in the show could have communicated with Salamanca. There's one scene in which Salamanca is trying to expose Walter as an infamous meth manufacturer to his nephew Tuco, but Tuco isn't able to properly understand what his uncle is trying to say. At that moment, I was thinking, if only they both knew Morse, right?. Later on, Salamanca gets reunited with his other nephews, Leonel and Marcos. Then, something incredible happens. They used a Ouija board to communicate with him. At that time I thought, WOW, that's much better than Morse, I even felt dumb for not thinking of it. Then, Salamanca is sent to a nursing home where he has access to an alphabet board, specifically designed to help non-verbal people communicate. At that point, I felt like designing something around the use of a Ouija board was just reinventing the wheel. So let's face it, the rule of thumb is if we are looking to solve a problem, the first thing you should do is to search for how others are dealing with it now. Doing so will probably lead you in the right direction. To feel better, I decided to do an Angular application with a digital alphabet board. What's an alphabet board? > Also referred to as a letter board, an alphabet board is a tool, used by people with certain disabilities, to communicate with others. Users do this by pointing to symbols on the board. These symbols include letters, numbers, signs, and even frequently used words. I started thinking that if I was going to learn about accessibility, working with an accessibility tool is the best way to go. An alphabet board seemed like a fun idea- listing the alphabet, going through all the letters, allowing the user to react to letters as a manner of input to build phrases. I decided to use the click as the interaction for this example, but it can be changed to anything else. When using non-digital boards, there's often someone holding the board and systematically scanning through each symbol, giving the user the opportunity to select symbols using a mutually agreed upon signal. The digital version has to automatically go through the letters, and select when receiving clicks. Now that you have an idea of what this will look like, let's go back to accessibility concepts in order to understand how to properly tackle the project. Accessibility > Accessibility, as it relates to digital technologies, refers to the design of products, devices, services, or environments, so they can be usable by people with disabilities. You may already be thinking of ideas to optimize the board's design and function. Your initial thought may be to add some kind of outline to the active letter while going through the alphabet. But what if the user has a visual impairment? That leads us to the first principle in WCAG, Perceivable_. Perceivable > Users must be able to perceive the information being presented (it can't be invisible to all of their senses). WCAG In order to say that the alphabet tool is truly accessible, users with visual impairments have to be able to use it. There has to be some mechanism to let the user know the currently active letter by sound. Although it may look like this is the only principle you are applying, if you create an alphabet board that can be easily placed in HTML, users like Salamanca will be able to best operate this tool. This falls into the second principle in WCAG, Operable_. Operable > Users must be able to operate the interface (the interface cannot require interaction that a user cannot perform). WCAG Helping users like Salamanca use web applications is taking this principle to the next level. It can literally change lives. Solution Now, instead of teaching Morse to all patients and nurses, let's build an easy to use alphabet board for people who are non-verbal. In the previous image, you can see the tool built by IBM for Stephen Hawking. I didn't have a huge crew to pull this off, so I'm going to walk you through a simpler version I created. Design The alphabet should be stored as a list of letters; the user interface has to show all the letters in the alphabet, separated by space. It has to have a time interval while the letter is active. When the user clicks, the currently active letter is stored as part of the word. In order for it to work, there has to be some kind of store, keeping track of the state of the letters that have been added to the word. Implementation Let's get to it. Our first step is to build the array of letters. The standard use for electronic communication encoding is named ASCII, in which the upper case letter A is represented by the integer 65. Since it's ordered, we can assume that 66 is upper cased B, and so on, until we reach the length of the alphabet (26). One of the possible ways to generate an array containing the integers from 65 to 90 in typescript is: `typescript const charCodes = Array.from(Array(26), (, index) => 65 + index); ` You may be wondering, Now what? The user has to do the math to see the current letter? The short answer is no. The long answer is that we can use a custom pure pipe to map the charCodes to their respective letter. That pipe can look like this: `typescript @Pipe({ name: 'char' }) export class CharPipe implements PipeTransform { transform(keyCode: number) { return String.fromCharCode(keyCode); } } ` Which can be used this way: `html {{ charCode | char }} ` Our next step will be to display them in the UI for the user. That can be done like this: `html {{ charCode | char }} ` What about the active letter? How will the user be visually notified of the currently active letter? That's easy. We create a modifier class in css for that. It can be something like this: `css .active { outline: 2px solid red; } ` The Alphabet board is now pretty useless. We need it to move if we want to allow users to use it by themselves. > RxJs to the rescue! For the board to move, it is required to have an interval running that will loop through the items in the letters array. We want it to go back to the start once it reaches the end of the list. Also, the .active` class depends on the currently active letter, so you are going to need some Angular magic too. `typescript index$ = timer(0, 2000).pipe(map(tick => tick % (this.letters.length + 1))); ` `html {{ charCode | char }} ` We are close! The board is there, and it already moves automatically. Now is the time to listen to interactions, and save the currently selected letter, as well as the word stored so far. `typescript select = new Subject(); word$ = withLatestFrom(this.index$, (, index) => String.fromCharCode(index)), scan((state: string, letter: string) => state + letter, '') ); handleClick = () => {; } ` `html {{ charCode | char }} {{ word$ | async }} ` You just did it! Your users are able to write words with it. > But what if I told you that's not completely true? Although there's a visual way to know the active letter, what about blind users? Remember, we are talking about inclusion here. You'll need to find a way to automatically notify screen reader users of which letter is currently active, and you will need to create a way to read out the word written so far. Thankfully ARIA exists, and it has a property that does exactly what we need. I'm not going to talk about ARIA specifically in this article, but you'll need it to get your alphabet board to the next level. To achieve this, you can use aria-live property. `html {{ index$ | async | char }} is active. {{ charCode | char }} {{ word$ | async }} ` And now, if you turn on a screen reader, you'll see how it notifies the active letter, as well as the word written so far. In case you don't want to create your own board, you can access my version of the alphabet board which looks like this: > NOTE: In order for the alphabet board to start, you have to click. Conclusion To wrap this up, I have to say that I personally had a lot of fun doing the Alphabet Board, and I really hope you do too. Many think that accessibility is a matter of following rules and compliance, but there is more to it. It is a way of designing what we build. > NOTE: This article is not related to compliance and rules. The intention is to give you a broader view of the accessibility aspect. If you are interested in being WCAG compliant, I'll release a new article about that soon. Icons made by Nikita Golubev from Flaticon...

I Broke My Hand So You Don't Have To (First-Hand Accessibility Insights) cover image

I Broke My Hand So You Don't Have To (First-Hand Accessibility Insights)

We take accessibility quite seriously here at This Dot because we know it's important. Still, throughout my career, I've seen many projects where accessibility was brushed aside for reasons like "our users don't really use keyboard shortcuts" or "we need to ship fast; we can add accessibility later." The truth is, that "later" often means "never." And it turns out, anyone could break their hand, like I did. I broke my dominant hand and spent four weeks in a cast, effectively rendering it useless and forcing me to work left-handed. I must thus apologize for the misleading title; this post should more accurately be dubbed "second-hand" accessibility insights. The Perspective of a Developer Firstly, it's not the end of the world. I adapted quickly to my temporary disability, which was, for the most part, a minor inconvenience. I had to type with one hand, obviously slower than my usual pace, but isn't a significant part of a software engineer's work focused on thinking? Here's what I did and learned: - I moved my mouse to the left and started using it with my left hand. I adapted quickly, but the experience wasn't as smooth as using my right hand. I could perform most tasks, but I needed to be more careful and precise. - Many actions require holding a key while pressing a mouse button (e.g., visiting links from the IDE), which is hard to do with one hand. - This led me to explore trackpad options. Apart from the Apple Magic Trackpad, choices were limited. As a Windows user (I know, sorry), that wasn't an option for me. I settled for a cheap trackpad from Amazon. A lot of tasks became easier; however, the trackpad eventually malfunctioned, sending me back to the mouse. - I don't know a lot of IDE shortcuts. I realized how much I've been relying on a mouse for my work, subconsciously refusing to learn new keyboard shortcuts (I'll be returning my senior engineer license shortly). So I learned a few new ones, which is good, I guess. - Some keyboard shortcuts are hard to press with one hand. If you find yourself in a similar situation, you may need to remap some of them. - Copilot became my best friend, saving me from a lot of slow typing, although I did have to correct and rewrite many of its suggestions. The Perspective of a User As a developer, I was able to get by and figure things out to be able to work effectively. As a user, however, I got to experience the other side of the coin and really feel the accessibility (or lack thereof) on the web. Here are a few insights I gained: - A lot of websites apparently tried_ to implement keyboard navigation, but failed miserably. For example, a big e-commerce website I tried to use to shop for the aforementioned trackpad seemed to work fine with keyboard navigation at first, but once I focused on the search field, I found myself unable to tab out from it. When you make the effort to implement keyboard navigation, please make sure it works properly and it doesn't get broken with new changes. I wholeheartedly recommend having e2e tests (e.g. with Playwright) that verify the keyboard navigation works as expected. - A few websites and web apps I tried to use were completely unusable with the keyboard and were designed to be used with a mouse only. - Some sites had elaborate keyboard navigation, with custom keyboard shortcuts for different functionality. That took some time to figure out, and I reckon it's not as intuitive as the designers thought it would be. Once a user learns the shortcuts, however, it could make their life easier, I suppose. - A lot of interactive elements are much smaller than they should be, making it hard to accurately click on them with your weaker hand. Designers, I beg you, please make your buttons bigger. I once worked on an application that had a "gloves mode" for environments where the operators would be using gloves, and I feel like maybe the size we went with for the "gloves mode" should be the standard everywhere, especially as screens get bigger and bigger. - Misclicking is easy, especially using your weaker hand. Be it a mouse click or just hitting an Enter key on accident. Kudos to all the developers who thought about this and implemented a confirmation dialog or other safety measures to prevent users from accidentally deleting or posting something. I've however encountered a few apps that didn't have any of these, and those made me a bit anxious, to be honest. If this is something you haven't thought about when developing an app, please start doing so, you might save someone a lot of trouble. Some Second-Hand Insights I was only a little bit impaired by being temporarily one-handed and it was honestly a big pain. In this post, I've focused on my anecdotal experience as a developer and a user, covering mostly keyboard navigation and mouse usage. I can only imagine how frustrating it must be for visually impaired users, or users with other disabilities, to use the web. I must confess I haven't always been treating accessibility as a priority, but I've certainly learned my lesson. I will try to make sure all the apps I work on are accessible and inclusive, and I will try to test not only the keyboard navigation, ARIA attributes, and other accessibility features, but also the overall experience of using the app with a screen reader. I hope this post will at least plant a little seed in your head that makes you think about what it feels like to be disabled and what would the experience of a disabled person be like using the app you're working on. Conclusion: The Humbling Realities of Accessibility The past few weeks have been an eye-opening journey for me into the world of accessibility, exposing its importance not just in theory but in palpable, daily experiences. My short-term impairment allowed me to peek into a life where simple tasks aren't so simple, and convenient shortcuts are a maze of complications. It has been a humbling experience, but also an illuminating one. As developers and designers, we often get caught in the rush to innovate and to ship, leaving behind essential elements that make technology inclusive and humane. While my temporary disability was an inconvenience, it's permanent for many others. A broken hand made me realize how broken our approach towards accessibility often is. The key takeaway here isn't just a list of accessibility tips; it's an earnest appeal to empathize with your end-users. "Designing for all" is not a checkbox to tick off before a product launch; it's an ongoing commitment to the understanding that everyone interacts with technology differently. When being empathetic and sincerely thinking about accessibility, you never know whose life you could be making easier. After all, disability isn't a special condition; it's a part of the human condition. And if you still think "Our users don't really use keyboard shortcuts" or "We can add accessibility later," remember that you're not just failing a compliance checklist, you're failing real people....

JavaScript Marathon: Building Your Own Style Framework With Vanilla Extract cover image

JavaScript Marathon: Building Your Own Style Framework With Vanilla Extract

Writing custom CSS throughout your app is time-consuming and error-prone. Relying on Tailwind or similar frameworks locks you into their way of doing things. But with Vanilla Extract, you can pursue the happy medium path: write type-safe CSS, create your own utility classes, and compile everything down to static CSS files at build time. Tom walked us through how to setup and use Vanilla Extract to create themeable CSS architecture in our example app. Helpful links__ - GitHub repo: - Youtube video: To learn more about Vanilla Extract, head over to their docs for a more detailed look into what working with Vanilla Extract is like. With Vanilla Extract, we don't need to run any CLI commands like other processors. We create the appropriate *.css.ts` files which get evaluated at build-time, and turned into properly scoped class names. One thing to point out is our example is uses Vite. Don't forget to look at the config file we've modified that will look slightly different than the basic one created by the Vite CLI. Install the dependencies You can also reference the complete setup docs. > npm install @vanilla-extract/css @vanilla-extract/webpack-plugin Create our folder structure Let's get started by creating our folder structure that will hold our theme definitions. In the end, your folder structure is entirely up to you, but for the sake of this example, we will create a theme folder__ and within that we will add __theme.css.ts__. In this file, we will describe our different themes. We also have a sprinkles folder__ which is where we define our "utility classes" of sorts. It operates in a similar way to how TailwindCSS operates. These sprinkles are styles we can include in other parts of our code. We can see in our sprinkles file how we have defined certain custom styles. And if we head over to our button.css.ts, we can see where and how our custom styles are used. It's like creating style variables within our CSS so we can keep a relatively consistent design feel across our app. Our defined CSS styles will return classes with our properties defined. This is an example class from our Button/index.tsx`: `className={buttonStyle[color]}`. This is a simple way to add different variants and styles to our components without bloating the component itself. For the sake of covering all our bases, we also defined a few global styles. Wrap-up Have a look at the example repo for a detailed look at how to use Vanilla Extract in a more in-depth way. We hope this has helped you understand how Vanilla Extract is used at a higher level, and how you can leverage it to create your own type-safe CSS styles....

Nuxt DevTools v1.0: Redefining the Developer Experience Beyond Conventional Tools cover image

Nuxt DevTools v1.0: Redefining the Developer Experience Beyond Conventional Tools

In the ever-evolving world of web development, Nuxt.js has taken a monumental leap with the launch of Nuxt DevTools v1.0. More than just a set of tools, it's a game-changer—a faithful companion for developers. This groundbreaking release, available for all Nuxt projects and being defaulted from Nuxt v3.8 onwards, marks the beginning of a new era in developer tools. It's designed to simplify our development journey, offering unparalleled transparency, performance, and ease of use. Join me as we explore how Nuxt DevTools v1.0 is set to revolutionize our workflow, making development faster and more efficient than ever. What makes Nuxt DevTools so unique? Alright, let's start delving into the features that make this tool so amazing and unique. There are a lot, so buckle up! In-App DevTools The first thing that caught my attention is that breaking away from traditional browser extensions, Nuxt DevTools v1.0 is seamlessly integrated within your Nuxt app. This ensures universal compatibility across browsers and devices, offering a more stable and consistent development experience. This setup also means the tools are readily available in the app, making your work more efficient. It's a smart move from the usual browser extensions, making it a notable highlight. To use it you just need to press Shift + Option + D` (macOS) or `Shift + Alt + D` (Windows): With simple keystrokes, the Nuxt DevTools v1.0 springs to life directly within your app, ready for action. This integration eliminates the need to toggle between windows or panels, keeping your workflow streamlined and focused. The tools are not only easily accessible but also intelligently designed to enhance your productivity. Pages, Components, and Componsables View The Pages, Components, and Composables View in Nuxt DevTools v1.0 are a clear roadmap for your app. They help you understand how your app is built by simply showing its structure. It's like having a map that makes sense of your app's layout, making the complex parts of your code easier to understand. This is really helpful for new developers learning about the app and experienced developers working on big projects. Pages View lists all your app's pages, making it easier to move around and see how your site is structured. What's impressive is the live update capability. As you explore the DevTools, you can see the changes happening in real-time, giving you instant feedback on your app's behavior. Components View is like a detailed map of all the parts (components) your app uses, showing you how they connect and depend on each other. This helps you keep everything organized, especially in big projects. You can inspect components, change layouts, see their references, and filter them. By showcasing all the auto-imported composables, Nuxt DevTools provides a clear overview of the composables in use, including their source files. This feature brings much-needed clarity to managing composables within large projects. You can also see short descriptions and documentation links in some of them. Together, these features give you a clear picture of your app's layout and workings, simplifying navigation and management. Modules and Static Assets Management This aspect of the DevTools revolutionizes module management. It displays all registered modules, documentation, and repository links, making it easy to discover and install new modules from the community! This makes managing and expanding your app's capabilities more straightforward than ever. On the other hand, handling static assets like images and videos becomes a breeze. The tool allows you to preview and integrate these assets effortlessly within the DevTools environment. These features significantly enhance the ease and efficiency of managing your app's dynamic and static elements. The Runtime Config and Payload Editor The Runtime Config and Payload Editor in Nuxt DevTools make working with your app's settings and data straightforward. The Runtime Config lets you play with different configuration settings in real time, like adjusting settings on the fly and seeing the effects immediately. This is great for fine-tuning your app without guesswork. The Payload Editor is all about managing the data your app handles, especially data passed from server to client. It's like having a direct view and control over the data your app uses and displays. This tool is handy for seeing how changes in data impact your app, making it easier to understand and debug data-related issues. Open Graph Preview The Open Graph Preview in Nuxt DevTools is a feature I find incredibly handy and a real time-saver. It lets you see how your app will appear when shared on social media platforms. This tool is crucial for SEO and social media presence, as it previews the Open Graph tags (like images and descriptions) used when your app is shared. No more deploying first to check if everything looks right – you can now tweak and get instant feedback within the DevTools. This feature not only streamlines the process of optimizing for social media but also ensures your app makes the best possible first impression online. Timeline The Timeline feature in Nuxt DevTools is another standout tool. It lets you track when and how each part of your app (like composables) is called. This is different from typical performance tools because it focuses on the high-level aspects of your app, like navigation events and composable calls, giving you a more practical view of your app's operation. It's particularly useful for understanding the sequence and impact of events and actions in your app, making it easier to spot issues and optimize performance. This timeline view brings a new level of clarity to monitoring your app's behavior in real-time. Production Build Analyzer The Production Build Analyzer feature in Nuxt DevTools v1.0 is like a health check for your app. It looks at your app's final build and shows you how to make it better and faster. Think of it as a doctor for your app, pointing out areas that need improvement and helping you optimize performance. API Playground The API Playground in Nuxt DevTools v1.0 is like a sandbox where you can play and experiment with your app's APIs. It's a space where you can easily test and try out different things without affecting your main app. This makes it a great tool for trying out new ideas or checking how changes might work. Some other cool features Another amazing aspect of Nuxt DevTools is the embedded full-featured VS Code. It's like having your favorite code editor inside the DevTools, with all its powerful features and extensions. It's incredibly convenient for making quick edits or tweaks to your code. Then there's the Component Inspector. Think of it as your code's detective tool. It lets you easily pinpoint and understand which parts of your code are behind specific elements on your page. This makes identifying and editing components a breeze. And remember customization! Nuxt DevTools lets you tweak its UI to suit your style. This means you can set up the tools just how you like them, making your development environment more comfortable and tailored to your preferences. Conclusion In summary, Nuxt DevTools v1.0 marks a revolutionary step in web development, offering a comprehensive suite of features that elevate the entire development process. Features like live updates, easy navigation, and a user-friendly interface enrich the development experience. Each tool within Nuxt DevTools v1.0 is thoughtfully designed to simplify and enhance how developers build and manage their applications. In essence, Nuxt DevTools v1.0 is more than just a toolkit; it's a transformative companion for developers seeking to build high-quality web applications more efficiently and effectively. It represents the future of web development tools, setting new standards in developer experience and productivity....