DEV Community: Carme Mias

Intro to accessibility testing

Carme Mias — Sun, 18 May 2025 10:59:06 +0000

You’ve probably already heard we should make all our front-end work accessible. It helps make sure everyone can have the best experience when using the digital services, products, or platforms we've created.

But how do we know whether our work is accessible? The most efficient way is to make testing part of our routine.

In this post I'll share some freeby tools and strategies that I use from my local dev environment and that you can start using today.

Browser extensions

First, I check the page being tested with a browser extension. This is the best way to catch the most obvious issues.

The three browser extensions recommended by gov.uk are:

Although it is not a browser extension, the Lighthouse tab in the Chrome DevTools is also useful and will give you similar results.

It's important to keep an eye out for false positives!

Keyboard navigation

Next, I check that the page can be navigated using only a keyboard with the following key combinations:

Tab or Shift + Tab to move focus to next or previous focussable element
Spacebar or Shift + spacebar to scroll down or up a page
Return key to click a focussed element
Arrow keys to navigate within menus and lists

As you move around the page, you should look out for the following:

Can you tell which element, if any, has focus?
Can you reach and interact with all enabled, clickable elements (buttons, links, form fields)?
Is the order in which these clickable elements get focus logical? or does focus jump around?
Is focus lost at any point? This may happen if the focussed element is hidden.
If there is a modal, external widget, or iframe in the page, can you navigate in and out of it? Can you open and close it as expected?

Screen readers

Testing with a screen reader, is slightly less straight-forward as we must also think about which browser we’re using for the tests.

The recommended browser pairings for the three main screen readers are:

JAWS with IE or Chrome
NVDA with Firefox
VoiceOver with Safari

Which screen reader?

JAWS is the most widely used screen reader in real life. However, it is proprietary software and its license is not cheap. As a consequence, most developers will only be able to test against it if their workplace owns a license.

NVDA is Open Source and the second most popular screen reader, although a version exists for Windows only. So if you work with a Mac or Linux laptop you may need to install it in a virtual machine.

VoiceOver comes built-in with iOS so, again, if you work with another operating system, you’ll need to use a virtual machine.

The recommendation is to test your work against as many screen readers as you can get hold of as they sometimes give different results.

How to use them?

Each screen reader has its own combination of keystrokes, so I’d advice downloading a cheatsheet and spending some time becoming familiar with them.

You can find all the screen reader cheatsheets on the Deque website.

Once you’ve got some practice under your belt, you’re ready to start testing your frontend work.

Here’s the steps and what to check for each:

Page navigation:
- Is the main site navigation useable? Does it include a skip to content link?
- If there is a secondary navigation element, is its purpose announced?
- Are all regions, headings, and links well defined and findable?
If there is a form:
- Can you interact with all its elements as expected?
- Test also the unhappy path. If a warning or error is displayed, does the screen reader announce it?
Read the whole page through.
- Is any information missed?
- Is there any repetition?
- Is anything read that could lead to confusion?

I realise this is quite a lot of information. And that it can potentially also be perceived as quite a lot of extra work!

What worked best for me was to add the checks to my workflow one at a time, in the order mentioned above. Once I was familiar and comfortable with one, I added the next.

Just think of the time saved by not having to go back to fix accessibility issues! Plus the satisfaction of delivering top quality work. Priceless!

How to migrate a Rails app from Bootstrap to Bulma

Carme Mias — Sat, 15 Feb 2025 16:54:26 +0000

The first thing to do is remove the Bootstrap-related gems from the Rails app.

Uninstall Bootstrap

From the terminal, cd into your project’s folder and type, for example:

gem uninstall bootstrap-sass bootstrap-will_paginate

Then run bundle install to update the environment.

Add Bulma

According to the installation docs, if you are happy to use the Bulma styles as they come, the last step you'll need to do is add the pre-compiled Bulma stylesheet to your document header:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bulma@1.0.2/css/bulma.min.css">

Otherwise if, like me, you want the option to customise the styles, you’ll need to add the Bulma npm package into your project.

Before doing that though, if your Rails app doesn’t have them yet, you’ll need to install nvm, nodejs, and npm. Follow the Node official instructions for the best way of doing this.

Use the cssbundling-rails gem

Once your environment is ready, you can install the cssbunding-rails gem. This gem saved me so much time!

cssbunding-rails can be used to install multiple CSS frameworks, not just Bulma. Check out the gem repo to find the whole list. It will also configure the app to compile the CSS styles locally.

To install cssbunding-rails and the Bulma package, run the following from the terminal:

bundle add cssbundling-rails bin/rails css:install:bulma

Note that running bundle add is equivalent to running gem install followed by bundle install.

Update all classes

The last remaining step is to migrate all the existing CSS classes in the app templates, views and partials from Bootstrap to Bulma.

A bit tedious but necessary.

And, do not forget to update your tests too!

After that, congratulations! All’s done!

A gotcha

Or perhaps not?

After the migration, the app run locally but my integration tests were failing with a weird error:

ActionView::Template::Error: Error: Invalid CSS after "...-s), var(--l));": expected "}", was "--00-l: var(--bulma" on line 14482:46 of stdin

It turns out I still had sassc-rails in the Gemfile. This compiler gem does not recognise some of the more up-to-date Sass included in Bulma and was causing the errors.

In any case, sassc-rails was no longer needed as cssbundling-rails does it all for us. So the solution, in the end, was easy:

gem uninstall sassc-rails

That’s it.

Commit, push. All done!

Why are we so rubbish at accessibility?

Carme Mias — Sat, 11 Jan 2025 08:32:25 +0000

Anybody working in the tech industry would agree that, as software developers, we pride ouselves on building beautiful, secure products properly.

We take care of the details. We keep ourselves and our code up-to-date with the latest news and versions. We patch, review, comment, refactor, and marvel at the sight of dry, clean code and fast response times.

So, please tell me, why are we so rubbish at accessibility?

Yes, we are rubbish

Strong words, I know, but in my opinion completely justified. Otherwise, how do you explain the terrible WebAIM Million report results, year after year?

95.9% of the top million website homepages have accessibility errors. The average is 56.8 errors per page.

“Ah, but accessibility is hard“, you may say.

To which my answer is: “Not all of it is“.

The most common failures, as identified by the report, definitely are not the hardest to fix. According to the latest report, the most common accessibility errors are:

Low colour contrast (81% of homepages)
Missing alternative text for images (54.5% of homepages)
Missing form input labels (48.6% of homepages)
Empty links (44.6% of homepages)
Empty buttons (28.2% of homepages)
Missing document language (17.1% of homepages)

We are clever people, in general 😉. Surely we can do better!

The documentation is definitely all out there and, let me tell you, it is not rocket science.

But why?

Unfortunately, we can only guess what the reasons behind such dyre report results may be.

Perhaps it could be due to time constraints, and being overstretched. Something has to give and, if it was ever in the roadmap, accessibility tends to be easy to drop, right?

If I was feeling generous, I may think it was due to lack of awareness. But this just smells of a lazy excuse. We are well informed folks, we have to be if we are any good at our jobs.

It could be lack of interest. There’s an adrenaline rush to cracking that gnarly bug, or getting your well researched and spiked architecture design approved. Double checking whether that form is accessible or that table understandable? Nah, boring!

It’s not all on us

OK, I have been a bit harsh. I agree.

Accessibility work is not only on us: graphic designers, copy writers, social media experts, product onwers, and ultimately company execs should also be on top of it.

In reality most of us know that accessibility is everybody’s work.

But as developers, we are the last link in the chain. We build the actual stuff that gets served to the general public and our customers.

Let’s take ownership

We can make a difference. We can change the outcome if we care enough to give it our attention.

Any software developer worth their salt would want to make sure 100% of their audience has a smooth, and enjoyable experience when using their product. Right?

According to a report from the UK House of Commons Library,

25% of the UK population report having a disability.

Yes, you’ve read correctly.

So, let’s stop ignoring the 25% of our audience who are disabled.

This 2025, put your time to good use by learning more about accessibility and aim to embed it into your daily workflow.

Your career, end users, and company’s bottom line will thank you for it.

Here’s to a happy, fruitful 2025! 🎉

Copy HTML content with navigator clipboard

Carme Mias — Wed, 13 Dec 2023 08:20:52 +0000

We have often seen “Copy” buttons for plain text. Thanks to navigator.clipboard‘s API, we can also programatically copy and paste HTML content.

The copy code

Let’s imagine we have a bit of HTML content that includes links and other basic HTML code. We want our end users to be able to copy it exactly as it is and use it elsewhere.

For this exercise, we will be working with a simple HTML page with a section with id=”copy-content” that contains the HTML to be copied, and a “Copy to clipboard” button, with id=”copy-button”. The code for this example can be found in this gist.

Initially, the javascript that makes it all happen looks like this:

const copyButton = document.getElementById("copy-button");
copyButton.addEventListener("click", copyContent);

function copyContent() {
  const content = document.getElementById("copy-content").innerHTML;
  addHtmlToClipboard(content);
}

function addHtmlToClipboard(content) {
  const type = "text/html";
  const blob = new Blob([content], { type });
  const data = [new ClipboardItem({ [type]: blob })];

  navigator.clipboard.write(data).then(
    () => {
      console.log("copied to clipboard");
    },
    () => {
      console.log("failed to copy to clipboard");
    },
  );
}

First, we add a “click” event to the “Copy to clipboard” button so that, when the button is clicked, the copyContent function is executed.

This copyContent function, gets the HTML content we want to copy and passes it to the addHtmlToClipboard function.

The addHtmlToClipboard function then takes this content, converts it into an HTML Blob and creates a new ClipboardItem with it. This is then writen into the clipboard using navigator.clipboard.write.

If the clipboard API succedes, the content is ready to be pasted elsewhere. For example, in a Word document or an email.

Note the inline CSS it is also copied but not that which is in a separate file.

Firefox gotcha

Unfortunately the ClipboardItem funtionality is not yet supported by all browsers, notably Firefox.

As a compromise, we can change the code so that at least the text content is copied to clipboard if the full functionality cannot be used. Here is the updated code:

const copyButton = document.getElementById("copy-button");
copyButton.addEventListener("click", copyContent);

function copyContent() {
  const content = document.getElementById("copy-content").innerHTML;

  if(typeof ClipboardItem === "function") {
    addHtmlToClipboard(content);
  } else {
    const textContent = sanitize(content);
    addTextToClipboard(textContent);
  }
}

function addHtmlToClipboard(content) {
  const type = "text/html";
  const blob = new Blob([content], { type });
  const data = [new ClipboardItem({ [type]: blob })];

  navigator.clipboard.write(data).then(
    () => {
      console.log("copied html to clipboard");
    },
    () => {
      console.log("failed to copy html to clipboard");
    },
  );
}

// removes all HTML tags and empty spaces at either end
function sanitize(content) {
  const pattern = /<\/?[\w ="'-:;\/\.]+>/g;

  return content.replaceAll(pattern, "").trim();
}

function addTextToClipboard(text) {
  navigator.clipboard.writeText(text).then(
    () => {
      console.log("copied text to clipboard");
    },
    () => {
      console.log("failed to copy text to clipboard");
    },
  );
}

So what has changed? First of all, after getting the content to be copied, the copyContent function checks whether the ClipboardItem functionality is available.

If it is, the addHtmlToClipboard function is run just as before. If it isn’t available, the new addTextToClipboard function is run instead.

This new addTextToClipboard takes the content to be copied, removes all traces of HTML code from it (via the sanitize function) and then writes it as text into the clipboard using navigator.clipboard.writeText.

From the callbacks, instead of console.logs, you could for example trigger a success notification or failure warning.

Try it out to see it working!