DEV Community: Emma Dawson

Consistent design

Emma Dawson — Sat, 31 Aug 2024 12:24:29 +0000

This blog post idea was sparked by an app I downloaded which had very inconsistent design and caused me confusion in the first few days of using it. Even now, I still find it illogical and somewhat hard to use.

So what is consistent design?

Consistent design refers to the practice of maintaining uniformity in the visual, interactive, and content elements across a website or application. This includes using the same colors, fonts, button styles, navigation patterns, and terminology throughout a site/app. Consistency helps users quickly understand and predict how the interface will behave, making it easier to interact with.

Consistent design and WCAG

Consistency is mentioned in three WCAG 2.2 criteria.

3.2.3 Consistent Navigation states that navigational mechanisms repeated on multiple web pages occur in the same relative order each time they appear. This is usually not a problem when websites are build with component-based systems and the same navigation is used across the whole site.
3.2.4 Consistent Identification states that components with the same functionality should be identified consistently. For example, a button within a multistep form should not be called "Next" on one page, "Continue" on the next and "Proceed" on the next but they should all use the same button text.
3.2.6 Consistent Help states that if a website has help mechanisms, such as a chatbot, or contact information, it should occur in the same relative order on every page so that it is easy to locate wherever you find yourself in the website.

There is no mention of consistency being a requirement anywhere else but it sure does help make your app or website more usable.

Why Consistent Design Matters for Accessibility

Predictability Enhances Usability: Consistent design allows users to build a mental model of how the website or application works. When users can predict what will happen when they interact with certain elements, they are more likely to have a smooth and efficient experience. This predictability is especially important for users with cognitive disabilities, who may struggle with processing complex or changing interfaces.

Reduces Cognitive Load: Cognitive load refers to the amount of mental effort required to use a website or application. When design elements are inconsistent, users must spend additional time and energy understanding each new interaction. For people with cognitive impairments, this can be overwhelming. A consistent design reduces the cognitive load by allowing users to focus on the content and tasks rather than figuring out how to navigate the interface.

Improves Navigation for Screen Reader Users: Screen readers rely heavily on consistency in design to provide accurate and understandable information to users who are blind or visually impaired. For example, consistent use of headings, lists, and landmarks ensures that screen reader users can easily navigate through content and understand its structure. When design elements are consistent, it reduces the likelihood of confusion and errors.

Facilitates Keyboard Navigation: Many people with motor disabilities rely on keyboard navigation to interact with digital interfaces. Consistent design ensures that interactive elements, such as buttons, links, and form fields, behave in the same way across the site. This predictability allows users to confidently navigate using the keyboard, without having to guess where they can tab to next or what each key press will do.

Enhances Readability and Comprehension: Consistent typography, color schemes, and content layout contribute to better readability and comprehension, which is crucial for users with visual impairments or learning disabilities. For instance, maintaining a consistent heading hierarchy helps users understand the structure of content, while consistent color contrast ensures that text is legible for those with color vision deficiencies.

Supports User-Centered Design: Consistency is a fundamental principle of user-centered design, which aims to create products that meet the needs and preferences of users. By adhering to consistent design practices, you not only improve accessibility but also ensure that your design is intuitive and user-friendly for everyone.

The inconsistent app: NYT Games

I enjoy playing wordle and doing sudoku so I decided to download this app to do the puzzles when I commute to work. Finding the games is not a problem; there's one main screen with all the puzzles as soon as you open up the app.

The problem comes with the end screens for each of the games. When I finish a game and have had time to check my results on the end screen I want to go back to the main screen with all the other puzzles directly. This is also what 68% of other people want to do too (according to my very scientific twitter poll).

Some end screens allow me to do this. However, others make me go back to the game first and others want me to go to another game, even if I've already played it. Sometimes there's an "X" button in the top right corner to close the game, sometimes there's a back arrow in the top left and sometimes there's a "View all games" button in the middle lower third of the screen. Very confusing!

The wordle end screen shows statistics and two large Call to Action (CTA) buttons to explore the wordle archive or play Spelling Bee. To return to the main page I need to press the small x in the top right corner and then press the back arrow in the top left corner of the game. There is no way to go to the main page directly.

After playing a game called strands I have two large CTA buttons to share results or play Spelling Bee. There is a back arrow in the top left corner which takes me directly back to the main page.

The Connections endscreen also allows me to share my results or play Spelling Bee. In the top right corner there is a "Back to puzzle X" button which I have to click first before returning to the main page. Notice here that button has text and an icon whereas the wordle screen only used an icon.

For the mini corssword endscreen we again have an icon only button up in the top right corner and I'm forced to go back to the game before going back to the main screen. Or I can of course play Spelling Bee which they seem determined that I do.

The Tiles endscreen is only half a screen that slides up from the bottom unlike the others. No cross here but finally a CTA button allowing me to "View all games" and go directly back to the main screen.

Finally the spelling bee endscreen they were so eager that I played. Again there is no close button in the top right corner but there is a "View all games" CTA button in the middle of the lower third of the page which takes me back to the main page.

Conclusion

Consistent design is a cornerstone of accessibility, making digital experiences more predictable, usable, and inclusive for everyone. By prioritising consistency in your design practices, you not only enhance the user experience but also ensure that your digital products are accessible to people with a wide range of abilities.

This is also something that could be fairly easily picked up with usability testing. If people struggle to use a site or app it may well be due to inconsistency in the design.

Accessible dropdown menus that pop up

Emma Dawson — Tue, 23 Jul 2024 15:33:41 +0000

The title of this article refers to one interaction that goes by many (sometimes confusing) names. You click a button that causes some previously hidden content to appear on the screen.

Examples may include clicking on a profile picture to see various profile options or having a multi-level navigation with top level buttons and nested links.

Do you call it a dropdown, a popup, a menu, a disclosure? A dropdown menu? A popup menu? Whatever you call it, let's look at how to make it more accessible.

The disclosure pattern

In this article, I'm going to refer to it as a disclosure. Why? Because it might not always drop down below a button and menu patterns are complicated and usually not needed on websites.

In this pattern, a user presses a button and something that was hidden is now visible - it is disclosed. Clicking away will hide the content again.

Our example

In this example, I'm going to be using a fairly basic multi-level navigation to demonstrate what's needed above and beyond semantic HTML to make the disclosure pattern accessible.

Here's what our navigation looks like:

It's a simple navigation with three sections: Our Services, About and Contact Us. Visually, we can see that Our Services and About are marked with down arrows suggesting that pressing these will open a disclosure. The lack of a down arrow on Contact Us suggests instead that we will be taken directly to that section.

The arrows also give us clues about the semantic HTML we should use. Pressing Our Services or About performs an action by opening a disclosure on the same page and therefore they should be buttons. Pressing Contact Us takes us to a different part of the site and should therefore be a link.

The HTML

Let's take a look at the HTML and the necessary attributes needed to get this working accessibly:

<nav>
  <ul class="nav-list">
    <li class="nav-group">
      <button id="navItem1" class="navItem" aria-expanded="false" aria-controls="disclosure1">Our Services &#9660;</button>
      <ul class="disclosure hidden" id="disclosure1">
        <li>
          <a href="#">Dropdown 1 - item 1</a>
        </li>
        <li>
          <a href="#">Dropdown 1 - item 2</a>
        </li>
        <li>
          <a href="#">Dropdown 1 - item 3</a>
        </li>
      </ul>
    </li>
    <li class="nav-group">
      <button id="navItem2" class="navItem" aria-expanded="false" aria-controls="disclosure2">About &#9660;</button>
      <ul class="disclosure hidden" id="disclosure2">
        <li>
          <a href="#">Our culture</a>
        </li>
        <li>
          <a href="#">Partnerships</a>
        </li>
      </ul>
    </li>
    <li class="nav-group">
      <a href="#">Contact Us</a>
    </li>
  </ul>
</nav>

We use the nav element around the entire component to indicate that this is a navigation. Within that we have an unordered list ul with three list items: the Our Services and About buttons using the <button> element and the Contact Us link using the <a> element.

The buttons require more than just HTML in order to be accessible. First we add an attribute aria-expanded="false". This let's screen reader users know that the disclosure attached to the button is not currently visible. We can change it to true with JavaScript when a user clicks on the button.

Each button also has aria-controls="disclosure-id" which links to the id attribute of the disclosure that belongs to it. This helps to identify which button controls each disclosure.

Nested inside each list item for the Our Services and About sections is another unordered list of the links that will be disclosed when the button is pressed.

In their initial state, the lists have the hidden attribute which means they are not announced to screen reader users and it is not possible to access them with a keyboard whilst closed. This attribute will also be controlled with JavaScript when the button is pressed and the disclosure becomes visible.

Adding the functionality

Now let's make it work. There's several things we want our component to do:

It should show the disclosure when the button is clicked once
It should hide the disclosure if the same button is pressed a second time
An open disclosure should close when the user activates another disclosure
The disclosure should close if a user presses the Escape key
The disclosure should close if a user tabs away from the last element to another element on the page

Opening and Closing the disclosure on button press

In order to open the disclosure we need to remove the hidden attribute and change aria-expanded to true. To make sure only one disclosure is open at once we loop over all of the buttons and make sure everything is closed first. Then we open only the one that was most recently pressed.

When we close the disclosure, we add back the hidden attribute and change aria-expanded back to false.

const navButtons = document.querySelectorAll(".navItem");
const disclosures = document.querySelectorAll(".disclosure");

function openNavigation(button) {
  button.setAttribute("aria-expanded", "true");
  // The ul is a direct sibling to the button
  const disclosure = button.nextElementSibling;
  disclosure.classList.remove("hidden");
}

function closeNavigation(button) {
  button.setAttribute("aria-expanded", "false");
  const disclosure = button.nextElementSibling;
  disclosure.classList.add("hidden");
}

function toggleNavigation(index) {
  // First we close any open disclosures not related to the 
  //current button in focus by looping over all nav buttons
  navButtons.forEach((button, buttonIndex) => {
    if (buttonIndex != index) {
      closeNavigation(button);
    }
  });
  const currentButton = event.target;
  const open = currentButton.getAttribute("aria-expanded");
  open === "false"
    ? openNavigation(currentButton)
    : closeNavigation(currentButton);
}

// Adds the toggle event to every top level button
navButtons.forEach((button, index) => {
  button.addEventListener("click", () => toggleNavigation(index));
});

Closing the disclosure with Escape

If the disclosure is open and a user presses the Escape key, we want the disclosure to disappear but, more importantly, we need to manage focus so that the user gets a good keyboard experience.

To do this we add an event listener for the Escape key, find the button which is connected to the open disclosure and use the .focus() method to send focus back to the button that originally opened the disclosure.

// This adds a global event listener to close any open disclosures when the escape key is pressed
window.addEventListener("keyup", (e) => {
  if (e.key === "Escape") {
    const navButtonsArr = Array.from(navButtons);
    const currentOpenButtonIndex = navButtonsArr.findIndex(
      (button) => button.getAttribute("aria-expanded") === "true"
    );
    // If there is an open disclosure, close it and send focus back to the button that controls it.
    if (currentOpenButtonIndex >= 0) {
      const currentOpenButton = navButtons[currentOpenButtonIndex];
      currentOpenButton.focus();
      closeNavigation(currentOpenButton);
    }
  }
});

Closing when the user tabs away

If a user tabs away then ideally the disclosure closes so that they can see any content underneath. You might first think that an onblur event on the last element will work for this. However, the onblur event gets triggered if you are tabbing backwards as well as forwards, which would prevent users from ever tabbing backwards from the last element in the disclosure. Instead, we'll check if the item in focus is within the disclosure. If not, we'll close it.

// This function closes an open disclosure if a user tabs away from the last anchor element in the list. It is reliant on the top-level list item of the top level ul having a class to find the group containing button + disclosure it controls
function handleBlur(button) {
  const navList = event.currentTarget.closest(".nav-group");
  if (!event.relatedTarget || !navList.contains(event.relatedTarget)) {
    closeNavigation(button);
  }
}

// This adds the handleBlur event to the last anchor element in each disclosure
disclosures.forEach((disclosure) => {
  const listItems = disclosure.querySelectorAll("li a");
  listItems[listItems.length - 1].addEventListener("blur", (event) => {
    handleBlur(disclosure.previousElementSibling);
  });
});

Final thoughts

It may seem like a lot of code for such a "simple" pattern and this is not even including the CSS to style it! It's probably not as much code when using something like React, so don't be scared away. The important thing is remembering the different fuctionality that needs to be added.

It's also important that we get used to adding in the code to make our components work for everyone, irrespective of the device they're using to access the content. And once you've done it a few times it will become second nature to add all the code needed to make every component accessible.

More accessible line graphs

Emma Dawson — Sat, 22 Jun 2024 18:34:12 +0000

Earlier this week, the State of JS 2023 survey results were published and, as always, the results are presented with a variety of different charts and graphs. Upon reviewing the line graphs, I noticed some common, easily fixable accessibility issues. In this post, I will discuss these issues and provide suggestions for improvement.

Use of colour alone

The line graphs are presented with a title, a legend, and the graph itself. However, these graphs rely on color alone to convey information. This is problematic because around 1 in 12 men (approx. 8% of the population) and 1 in 200 women (approx. 0.5% of the population) have a red-green color vision deficiency. Other types of color vision deficiencies mean that about 1 in 10 people may have difficulty distinguishing all the colors used.

We can emulate color deficiencies in Chrome to demonstrate how the graphs appear to people with these conditions.

Emulated protanopia (no red)

Without red, distinguishing between reds, oranges, yellows, and greens is challenging.

Emulated deuteranopia (no green)

Without green, it's also difficult to distinguish between reds, oranges, yellows and greens.

Emulated tritanopia (no blue)

Without blue, the blues and greens become difficult to distinguish and the reds and oranges also become harder to tell apart.

Emulated achromatopsia (no colour)

Without colour, all lines become a shade of grey.

What's the solution?

There are several ways to improve these graphs to ensure they do not rely on color alone.

Different Line Styles

Different line styles (e.g., dotted, dashed, and solid lines) can be used to differentiate the lines. Additionally, various shapes (e.g., circles, squares, triangles) can mark data points.

Here's an example using different shapes for each data point (albeit poorly photoshopped):

There are still some downsides with relying on a legend to communicate the relationship between data points and their category. Legends can be difficult to use for people with certain eye conditions or cognitive disabilities.

Label the Lines Directly

Labeling the lines directly removes the need for a legend, making it easier for users to identify each line. This approach may require more space on the y-axis to accommodate the labels, especially where lines overlap.

Here's an example with labels directly on the lines (again, a rough edit):

Alternative text and text alternative

I tested the graph with NVDA, a screen reader, and found that it was an unusable experience. The screen reader read out each element of the y-axis first, then the x-axis, but it didn't specify what these axes represented.

When it got to the graph, it was an unusable experience for anyone using a screen reader. Each part of the graph is made up of many paths in an SVG. NVDA went wild, reading "Graphic, clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable clickable..." and any normal person is left thinking "please make it stop!!!"

The SVG should be given a role="img" and then an alternative text between two <title> tags which describes the graph. And because these graphs present a lot of information, it should ideally be presented in another way such as in a table. Screen reader users can navigate through tables to get information but presenting info in another way is also useful for many other people.

Graphs are not the easiest things for many people to read. They require quite a lot of cognitive energy to work out what the different x and y axes are and what is being shown. Giving people the option of seeing data presented in different formats helps people to understand the way they can best.

In summary

A few small tweaks can significantly improve the accessibility of these line graphs:

Differentiate lines by more than just color.
Label lines directly whenever possible.
Avoid using legends if possible.
Present information in multiple formats, such as tables.

Implementing these changes will make the graphs more accessible and ensure that a broader audience can benefit from the valuable insights they provide.

Inaccessible forms

Emma Dawson — Sun, 02 Jun 2024 13:54:37 +0000

The other day I was attempting to book an airport transfer and came across a terrible form. It took me quite some time to work out how to actually book the transfer I needed and even then I wasn't convinced I was going to get to the airport on time.

The hotel I was staying at sent me a link to book the transfer. Opening the page, the form looked like this:

Before even touching the form, all fields are marked in red, suggesting errors. It's not great to start off with your form already in an error state before being touched.

Also, these errors are indicated with colour alone which means that anyone that doesn't perceive colours would have difficulty knowing there's supposedly anything wrong with these inputs.

The form does not have any error messages that show if a field is incorrectly filled in. They rely on changing the border of the input from grey to red. If there is an error with an input it should have a written error message close to the input field. An error icon next to the text would also help to indicate that it was an error text and not just supporting information.

Once you fill in the inputs, each one turns from red to grey. There doesn't seem to be any validation aside from the inputs not being empty. But then another problem:

I've filled in all the required fields, all the red is gone but the "Go Forward" button is still disabled. So now I'm sat staring at this form with no idea what is wrong and wondering if I will ever get to the airport in time to catch my flight. Can you work out how to fill in the rest of the form?

I did work it out eventually. There are three icons in circles at the top of the page labelled "Info", "Arlanda" (the name of the airport) and "To the hotel". The Info icon was coloured as that was the step I was on but the other two were greyed out. Turns out, greyed out in this case did not mean disabled, unlike the button at the bottom of the form. Clicking on the Arlanda icon took me to the second part of the form where I could enter the rest of the details needed to make the booking.

I finally got a confirmation, although after the state of this form I did not really trust it and had to double check with the hotel on arrival that it had indeed worked. I'm guessing they never did any user testing before releasing this into the wild!

So how do you make your forms better than this?

Don't start off in error mode
Indicate errors with more than just colour alone
Have clear written error messages for each input field
Avoid using disabled buttons wherever possible. It's better to let users press the button and see an error for why the form didn't submit than have to guess what they need to do to make the button not disabled
If something is clickable don't make it look disabled
Do some user testing! Surely one user test would have picked up how terrible this form is before ever going live in production?!

The European Accessibility Act != EN 301 549

Emma Dawson — Sun, 19 May 2024 18:19:49 +0000

I read a lot of blog posts about accessibility where people confuse the European Accessibility Act and EN 301 549 as being the same thing. While they both have roles in improving levels of digital accessibility, they are not actually the same. I'll admit it's something that confused me for a long time too, so I wanted to write about the differences.

What is the European Accessibility Act?

The European Accessibility Act (EAA) is a European directive.
Directives tell the 27 individual countries within the European Union (EU) what goals they must achieve and by when. Then each EU country has to create their own national laws that implement the goals of the EU directive.

The European Accessibility Act is converted into 27 national laws. In some countries this means writing entirely new laws and in others they add it to their already existing accessibility laws. The deadline for these laws to be transposed was 28th June 2022 and the deadline for implementation by (most of) the affected products and services is 28th June 2025.

The goal of the European Accessibility Act is to harmonise the level of accessibility across certain products and services within Europe, meaning anyone with a disability in Europe can expect a certain minimum level of accessibility wherever they are. It is also meant to promote a free market between any of the 27 member states by removing barriers that have previously been created by each country having their own differing laws.

What is EN 301 549?

EN 301 549 is a European technical standard of digital accessibility. It was also developed several years before the EAA was written.

It was originally designed for public procurement processes for digital services and products. This means it sets out actionable ways to meet the digital accessibility requirements for public sector services such as government organisations.

EN 301 549 incorporates the level A and AA criteria from the Web Content Accessibility Guidelines (WCAG) 2.1 standard into it. However, EN 301 549 includes other requirements on top of WCAG 2.1 that also need to be implemented in order to be considered accessible such as obeying user preferences for things like dark/light mode and font size.

Standards are easier to update compared to laws which is why many laws refer to specific standards. This means standards can be kept up to date with evolving technology. In the case of EN 301 549, this means it will probably update from WCAG 2.1 to WCAG 2.2 in the near future.

By fulfilling the requirements of a standard you, in turn, fulfil the requirements of the law.

So how do EAA and EN 301 549 relate to each other?

By now you might be thinking that the European Accessibility Act refers to the EN 301 549 standard. Fulfil EN 301 549 standards and you fulfil the requirements of the EAA. But funnily enough, the European Accessibility Act makes no mention of EN 301 549 at all.

However, a previous European law, the Web Accessibility Directive, which is targeted at public sector such as government bodies, does make reference to the standard.

Therefore, it is widely anticipated that EN 301 549 will also be the standard used to measure that any products and services falling under the new EAA live up to accessibility requirements set out in the directive. It would be impractical to have two separate standards to measure digital accessibility.

Conclusion

The European Accessibility Act is a legal directive that EU member states must implement into national law, while EN 301 549 is a technical standard likely to be used to measure compliance. They are distinct yet complementary.

Though it's unclear whether all or just parts of EN 301 549 will be required to meet the goals set out by the EAA, it's a safe bet to start improving your websites by adhering to at least the WCAG 2.1 A and AA criteria. This proactive approach will help ensure compliance and enhance accessibility even before the law comes into force.

Enhancing Accessibility: The Importance of Focus Management in User Interactions

Emma Dawson — Sat, 27 Apr 2024 15:33:25 +0000

In today's digital landscape, accessibility is not just a nice-to-have feature but a crucial aspect of creating inclusive user experiences. One often overlooked yet vital component of accessibility is focus management.

In this post, we'll look into what focus management is, and how it can greatly enhance the accessibility of your web applications.

Understanding Focus

Let's start with the basics: what exactly is focus? In web development, focus refers to the current interactive element on a page that will be activated if you hit the enter or space key. It's the cornerstone of keyboard navigation, allowing users to interact with various elements on a website without the need for a mouse.

Keyboard users move the focus forward between elements with the tab key (and sometimes arrow keys). The focus should always be visible, marked with a focus indicator. Browsers have built in focus indicators which are usually a blue or black outline around an element.

The browser default is classed as accessible even if the contrast is poor against the background. However, many designers take offence to the default indicator which all too often leads to a (very poor) decision to remove the outline indicator altogether. Please never do this. Always design a better focus indicator instead; one that stands out against the different background and foreground colours used in different parts of your site.

The Role of Focus Management

When a keyboard user presses the tab key the browser usually knows that it should move the focus to the next interactive element in the DOM tree. However, sometimes things happen on a website and the browser can't work out how to manage the focus. Examples include opening and closing modals, adding and removing elements from the DOM and changing pages in single page applications. When this happens, the developers need to jump in and help the browser out by telling it what to do.

Focus management involves programmatically moving the focus from one place to another using code when users interact with a website. This ensures that focus lands in the right place and users get a logical experience of the page.

Why Focus Management Matters

Keyboard users rely heavily on visual focus indicators to understand their current position on a webpage and navigate through interactive elements in a logical manner. A lack of focus management can be frustrating if you can't reach certain elements with a keyboard or focus lands in a strange place (such as the footer when loading a new page) leading to lots of extra tabbing.

Similarly, screen reader users depend on audio feedback to interact with content. Moving focus triggers a screen reader to announce the element where focus has been moved to. Without focus management, screen reader users often get no audio feedback and are left guessing whether an interactive element actually does something or not.

Without proper focus management, these essential cues may be missing, making the page challenging to use for individuals with disabilities.

Best Practices and Considerations

It is not always easy to know the best way to manage focus so it is important to conduct user testing whenever possible. It's important not to go overboard thinking that focus needs to be managed everywhere and it's just as easy to do too much as it is to do too little. We want to enhance accessibility without overwhelming people. So the best thing is to ask the people that need focus management the most.

If you are unable to do user testing, your next best option is to consult with accessibility experts to discuss what might be good options to consider.

And remember to include well-designed focus indicators that meet accessibility standards for colour contrast.

In conclusion, focus management plays a vital role in making web interactions more accessible to all users, particularly those with disabilities. By implementing proper focus management techniques, developers can create inclusive experiences that empower users to navigate and interact with digital content effectively.

In future posts, I will dive into specific interactions which can need focus management such as disclosure widgets, adding and removing items from the DOM, opening modals and handling route changes in single page applications. If there are any other interactions you'd like me to cover, feel free to drop a comment.

Focusing on focus indicators

Emma Dawson — Sat, 20 Jan 2024 15:11:55 +0000

Websites contain many interactive elements such as buttons, links and various types of inputs. While these elements are often activated by mouse or touch, there's a substantial minority of people that use keyboards or other input devices for navigation.

Navigating with Keyboards

Keyboard users navigate through websites using the tab key, moving from one interactive element to another in order. Focus indicators play a crucial role in this process, visually highlighting the element currently under keyboard control. Without them, it becomes a lot more difficult to know which interactive element will be activated when pressing the Enter or Space key.

Browser Defaults and Accessibility

Focus indicators are built into the browser by default and if left untouched, they automatically count as accessible even if browser defaults don't always meet all WCAG (Web Content Accessibility Guidelines) criteria such as color contrast.

At the time of writing this (Jan 2024), Chrome-based browsers on Windows provide a double-layered focus indicator with a black outline on the inside and a white outline on the outside. This means it's more likely to work with both light and dark backgrounds.

Firefox on Windows goes for a double-layered dark blue/light blue outline combination around buttons and a single blue ring around links.

So if they're already built into the browser, what's the problem?

Well, many people don't like the look of the default focus indicator, especially as they are not consistent across different browsers, and therefore use CSS to turn it off completely. Unfortunately, this leads to a much poorer user experience. So let's dive into how we can make a more accessible focus indicator.

Accessible Focus Indicators

Color Contrast

A focus indicator needs to have at a contrast of at least 3:1 for all adjacent (touching) colors. That means if the focus indicator surrounds a button it must contrast against the button background color and the background behind the button.

If you have sections of your site with different background colors or interactive elements that have different colors and one focus indicator doesn't work for all elements, it is possible to use CSS to style the focus indicator colors differently for different elements.

If you include different website themes, such as dark mode and light mode, you will also need to consider the color contrast for all themes.

Spacing around interactive elements

If you use an outline or a border as a focus indicator, leaving a small amount of space around an interactive element can also make it easier to spot which element has focus. This also means you only need to consider the focus indicator color constrast against the background color since the color of the interactive element is not directly touching the outline.

Double outlines

Double-layered outlines in two contrasting colors can be a good way to make focus indicators more flexible, especially if you're dealing with dark and light mode. This way, the dark part of the focus indicator will show on light backgrounds and the light part will show on dark backgrounds.

High contrast mode

Windows high contrast mode overrides most default colors with a minimal palette of highly contrasting colors. However, problems can arise if you've restyled your focus indicator and used

outline:none somewhere within your CSS. This means the focus indicator in high constrast mode will no longer be visible. Instead, use an outline set to transparent. This will not show up normally if you've restyled the focus indicator but will become visible in high contrast mode.

Another way to make sure focus indicators are visible even in high contrast mode is to use the forced-colors media query to apply specific styling. However, be careful to override forced colors sparingly, as the mode is styled the way it is for a reason.

Conclusion

Creating a more accessible focus indicator involves thoughtful consideration of color contrast, spacing, and adaptability to various modes. By understanding and addressing these factors, designers and web developers can contribute to a more inclusive online experience for all users, regardless of their chosen input device or accessibility needs.

Resources

Getting started with accessibility? Embrace the power of HTML

Emma Dawson — Sun, 06 Aug 2023 13:33:00 +0000

Be honest with yourself - how long did you spend learning HTML when you first started learning web development? For the majority of folks, 1-2 weeks is usually enough to understand the basics and get up and running, given the flexible and forgiving nature of the language. And then you move onto more complex things.

However, when we move on to more complex things we often miss out on learning about some of the things that HTML gives us for free, especially the inbuilt accessibility. So I’d like to encourage you to revisit HTML. It has over 100 different tags and a variety of attributes available. Many of those elements have built in features that make your site accessible without much extra effort (and sometimes even less).

Here are 10 tips to get started with writing more accessible HTML today:

Some elements are designated as landmarks. These include things like <nav> <header> <footer> and <main>. Although they may just seem like divs with fancy names, typing out the extra couple of letters helps people who use screen readers to navigate your site find their way to the different sections of a page more easily. Sighted users have the ability to scan pages and find what they’re looking for. Screen reader users can use landmarks to navigate sections in a similar way, instead of having to go through everything on the page.
Similar to landmarks, correct heading structure is another way that screen reader users can quickly find the information they’re looking for. Heading structure should be based on hierarchy and not styling. Each page should ideally contain a single h1, followed by multiple h2s. These h2s can be broken down into h3s if necessary. Just don’t jump from h2 to h4 because you want the headings to be different sizes. Here, CSS is your friend.
Focus on using correct semantic HTML, where the element matches its intended purpose. If it’s something you click and it takes you somewhere else then you probably want an <a> element. If you click something and it performs an action, such as opening and closing a menu, you probably want a <button>. These semantic elements have inbuilt functionality which allow them to be triggered by both mouse and keyboard without you needing to add any extra code. If you use a div to make a button you will need to add all the extra functionality yourself and that can be quite complex and easy to forget something.
Write clear and concise link text that accurately describes the link's destination. Avoid using vague terms like "click here" or "read more". Links should make sense even when read out of context so that users know where the link will take them.
Provide alternative text for visuals. All the images and icons on your page need descriptions for those that can’t see them. This is often called alternative text and is added to the img element with an alt=”Your description here” attribute. Provide enough information to understand why the image is there, and in the case of icons, you usually need to think about the function of the image and not what it actually depicts. For example, a magnifying glass is often used to symbolise both search and zoom. An alternative text matching the function is much more useful than describing the magnifying glass itself.
Make sure inputs have labels and that they are programmatically associated with each other. What does that mean? It means the label has a for attribute and the input has an identical id in order to show that they are connected. This tells screen readers and other assistive tech that the label belongs to the input.
Placeholders are not a good substitute for labels as they disappear as soon as someone tries to input something. This can be quite demanding on memory, especially if the placeholder text contains information about the format the input should be in. Clear labels that are always present next to the input gives a much better experience for everyone.
Prioritise Keyboard Navigation. This is crucial for users who rely on keyboard navigation due to motor disabilities. Start at the top of your page and start tabbing through the content. Can you reach every interactive element and is the order you tab through them logical? Can you see where your focus is at all times as you are tabbing through or does the visible focus disappear sometimes? Can you activate links with the enter key and buttons with the space or enter key? Often, if you’ve got semantic HTML right then this shouldn’t be a problem. If you come across issues, either go back and improve the HTML where possible or you’ll need to start adding appropriate keyboard support with javascript.
It’s perfectly fine to use <div> and <span> if there’s not a more appropriate semantic element. Divs and spans are invisible to the accessibility tree and therefore ignored by screen readers and other assistive technology. This makes them perfect to use for styling and positioning elements without making the screen reader experience too noisy.
Attributes are also useful. For example, adding the lang attribute to the <html> element informs assistive technology like screen readers which language to use. Screen reader will then adapt the output accordingly and read with the correct pronunciation.

Most of these changes take a couple of extra seconds but they can make a huge difference to how accessible your website is. Why not choose just one of the things suggested above and make it a new habit today? Small improvements over time add up in the long run.

Comparing accessibility: Hashnode vs. Dev.to

Emma Dawson — Sun, 02 Apr 2023 07:32:07 +0000

A couple of week's ago I asked on Twitter about good blogging platforms for developers. Aside from quite a few suggestions to build one myself with 11ty (which I may get to eventually) the two main contenders were Hashnode and Dev.to, but since accessibility is my jam in order to help me decide between the two I did some accessibility testing on both to see which has the better experience.

It may be a giveaway which platform won in my view, considering where I'm writing this, but here is the process I went through to decide. If you'd rather watch a video I also posted a review on Youtube. Otherwise, read on...

(Sidenote: the youtube video was filmed in February and some changes have been made to the sites since then. Some numbers/issues might have been fixed since then as I'm retesting as I write this blog post.)

The two sites are visually similar, with a header containing things like logo and search, a left sidebar containing navigation items, a central feed of blog posts and a right sidebar with things like statistics, trending search terms and challenges.

Automatic testing

First, I did some automatic testing with the chrome extension Axe Dev Tools. I was pleasantly surprised by the low score both websites had.

Dev.to scored 21 last month and is down to 15 today and Hashnode scored 15 last month and 17 today. The issues flagged were very similar. Both had id attribute values that were not unique, a few color contrast issues, problems with alternative text on some images and links or buttons without discernable text. Dev.to also had headings that increased by more than one level and Hashnode had frames missing accessible names. However, it's great to see that the score is decreasing on Dev.to.

Keyboard testing

Since automatic testing can only find around a third of accessibility issues, I continued by testing both sites with the keyboard. Starting at the top of the page I tabbed through the content and here is where the first major differences started to show up.

Previously testing Dev.to there seemed to be some hidden link before the Dev.to logo at the top of the page. I guessed it was a skip link that just wasn't visible. Great to see when I returned today that the skip link actually shows up on the page when you tab to it!

On the whole, focus indicators are clear and easy to follow around the screen. I only lost it a couple of times in a sidebar component about the Dev Community. However, the main downside with keyboard use is that for each card in the main feed there are way too many tab stops. I counted 15 on the top card alone. And then there's an issue that the feed has infinite scroll so it's actually impossible to ever reach the end and get to the right sidebar with only the keyboard.

Hashnode unfortunately faired even worse on the keyboard test. No skip link, a focus indicator that is only present on about half of the interactive items so most of the time I had no idea where I was on the page and an infinite scroll on the feed here as well so I couldn't reach the right sidebar. Each blogpost also had 15 tab stops but there was also 15 random profiles I had to tab through after the header and the nav in order to get to the main content so I felt like I was endlessly tabbing.

Screen Reader testing

For these tests I used NVDA on Windows and a Chrome browser.

On the whole, the screen reader experience on Dev.to is ok, if not a little verbose at times. Dropdowns are communicated as collapsed or expanded, buttons as pressed or unpressed and icons have accessible names. Some of those names are a little questionable, like the profile picture having the accessible name "Navigation Menu" but on the whole it's usable.

In the blog post cards they seem to have gone a little wild with adding the blogpost name to everything and given that there were 15 tabstops it got more than a little annoying. Also, the actual main navigation is placed inside an aside element which makes that more wordy than it really needs to be too.

Hashnode again was not such a great experience. There was no feedback as to whether dropdowns were open or closed, dark mode was on or off and some icons buttons that were just announces as "button". The main navigation was not announced as such and wasn't even announced as a list of links. Delving into the inspector this is because they've just placed links directly inside a div element. Blog post cards were again wordy as the blog post title had been added to things like the image too and the image was it's own separate link.

Other considerations

Dev.to is open source and has quite a comprehensive section in their documentation dedicated to accessibility. Even if they don't always get it right this tells me that accessibility is something they have considered. Also, the fact that improvements have been made in the time since I made the video and when I am writing this blogpost suggest they are actively working to make things more accessible. Also, because it's open source I feel like I can myself raise issues and make contributions when I have time, in order to make the experience better for everyone.

In contrast, Hashnode is not open source and I had a hard time finding anything in their documents/FAQs about accessibility. In the feature request section I found only one post where someone requested the focus indicator issue be addressed. That was posted over a year ago, had no comments and has obviously not been fixed yet which doesn't give me great confidence that accessibility is something they are actively working on.

Conclusions

As you can see, Dev.to is my choice for blogging at the moment, due to lack of time to make my own blogging website. I feel positive that they are doing their best to address accessibility issues and that it something I can help contribute to as well.

Women in Tech Sweden 2023

Emma Dawson — Sun, 26 Mar 2023 09:27:28 +0000

Equality (or lack thereof) is a hot topic within the tech world and current statistics show that only about 30% of the tech workforce in Sweden is made up of women (Source - Tech Sverige). When looking at software developers as a subset of that group that number falls to 19%. Women in Tech is a global movement aimed at empowering women in the tech industry, making sure they want to stay in the industry and finding ways to close the gender gap and encourage more young girls and women to join the industry.

On March 23rd, 2023 Women in Tech Sweden held their 10th annual conference and this year I was lucky enough to get a ticket. The day was jam-packed from start to finish with non-stop talks and seminars from a diverse group of women on a diverse range of subjects.

Atefah Sebdani talked about her disappointment at joining a company that she thought was diverse and inclusive only to find out that they didn’t walk the talk internally compared to the picture that was painted to the outside world. She stressed how much representation matters and that work and Mondays should be fun.

Mar Hicks talked about the gender shift that happened in the 60s and 70s when governments realised the potential importance of technology. Up until that time programming was heavily dominated by women and seen as a woman’s job. Politics pushed it in favour of men as it grew in importance.

Åsa Zetterberg from TechSverige shared how the tech industry adds 281 billion to the Swedish economy every year, and being a software developer is the 5th most common job in Sweden. Yet only 30% of people in tech are women and only 19% are software developers. Unfortunately the bias starts early. She talked about the need to get girls interested at an early age. I have personal experience of this as I used to be a teacher. In the age range I taught which was 9-12. In my experience boys and girls were both equally interested in coding at that age, quite often the girls were more interested. So we need to find a way to keep that interest alive.

Regina Nkemchor did a lightning talk on Diversity in Open Source projects. This one is near and dear to my heart because I love open source. Her 6 tips were:

Have an active code of conduct and make sure you enforce it
Use inclusive naming
Have mentorship programmes
Keep track of community health metrics
Have good process documentation
Make sure to have representation in leadership

Dr Angel K Durr gave a fascinating talk on cybersecurity and the war on data. The internet nowadays is essential for practically everyone but it’s only safe for some. She talked about how everyone will be the victim of cybercrime at some point and the likelihood of a catastrophic cyberattack happening within the next two years.

Sanne Fleming talked about strategies to manage cybersecurity such as having a regular cycle for updating and patching software, taking regular backups, managing access to services and multi factor authentication. She talked about the need for more education within this area in order to increase awareness about the kind of threats that exist.

Maria Bouzeid’s talk on innovation and sustainability presented an interesting overview of the problems we face with increasing electrification and the way current systems need to be totally reimagined to provide for such a demand for electricity in the future. The old ways can’t sustain new habits and a more circular system where consumers also become consumers is a likely future scenario.

If we think the gender gap in tech is bad, then in racing it's catastrophic. 14 year old Milla Sjöstrand talked about her dream to become the first woman in formula 1 in over 50 years and the eye-tracking technology she is using to help her achieve that goal. This technology is fascinating and I can see it could also be a major benefit within the realms of accessibility too.

Sustainability and circular economy was also the topic of a talk given by Hanne Hed and Rut Meyersson. They encouraged us to Rethink, Repurpose and Redesign in order to lead to a more regenerative future where we have less negative impact on the planet. They questioned why profit and growth should always be the end goal, and emphasised the importance of adding people and planet into what we measure in terms of success.

Tech ethics was the topic of discussion in a workshop by the company Tietoevry, asking the question

“How do we make sure we don’t cause more problems than we solve?”

There are lots of ethical dilemmas within the tech world and the decisions that get made can impact hundreds of thousands of people. They suggested asking questions such as “Should we build it?” and “What could go wrong and for whom?” when faced with plans to build new products and services.

Karin Zingmark gave a powerful talk on trust and how high trust teams are more productive and experience less stress. Her tips for establishing trust were to recognise excellence, share information broadly, focus on dialogue and asking questions, communication, building intentional relationships and being able to show vulnerability. The thing that stood out most for me in this talk however was a personal experience Karin shared. She had been experiencing some discriminatory behaviour by a colleague yet when she took it up with HR instead of HR dealing with the behavioural problem of the colleague they offered Karin a course on how to deal with the stress instead. Watch out for this kind of thing disguised as help.

Stephanie Darvil spoke passionately about the dangers of hustle culture and I love her quote

“Hustle culture is confusing privilege for passion”

The hustle culture is unhealthy and quite frankly that is off putting for a lot of people, but especially women.

Alice Heiman, Madeleine Majenburg and Annika Bäckström all talked about different dimensions of AI. The digital humans which seem to be the next step in chatbots seemed slightly creepy to me as their facial movements didn’t seem quite right but there’s definitely a lot of potential for new types of media and there’s no doubt that AI is becoming more and more prominent in everyday life.

The only man on the stage that day was the Minister for Education in Sweden, Mats Persson. It was great to hear him talk about the need to get more girls interested in tech at an early age and he seemed keen to find ways to help do that.

The final talk of the day was given by Azra Osmancevic and she asked us to contemplate these 6 questions:

Are you reconnecting with your passion and purpose?
Are you supporting life-long learning?
Do you balance humanity and technology?
Are you flippin’ the hierarchy upside down?
Are you unleashing your inner Yoda?
Can you do serious things without taking yourself too seriously?

So, what am I taking away from the conference?

If women are not part of tech then we’re also not part of shaping the future. The gap needs closing and that’s going to take a lot of different actions in order to achieve, such as education and training, addressing toxic workplace cultures, providing role models and mentors to the younger generations and a lot of advocacy and outreach work.

For me, it’s not just about unequal numbers of women vs men in the industry, this is also about diversity, equity, inclusion and accessibility for all underrepresented groups. I also don’t think we can achieve this by creating women’s only groups. We can’t reach equality by siloing ourselves. We need to create forums where everyone can meet in safe spaces and create solutions together. We need to advocate for ourselves and each other.

Although Women in Tech is a fantastic initiative and I had a blast at the conference wouldn’t it be awesome if conferences like this were no longer needed?