Forem: Sarah

Dataviz accessibility review: what we can learn from the Norwegian 2023 election graphs

Sarah — Wed, 13 Sep 2023 16:55:44 +0000

This was first posted on my blog: fossheim.io.

During the 2020 presidential election night in the United States, I reviewed the data visualizations used by the major US news networks, and used it to illustrate some dataviz accessibility dos and don’ts.

Now that Norway had its local elections (we were voting for a new regional and city government), it's time for a repeat of the concept and take a closer look at the dataviz accessibility of the graphs used in the Norwegian media.

Earlier this week the Norwegian news NRK reported that none of the Norwegian municipalities were conforming to web accessibility requirements, so I was definitely curious how the different charts would perform.

Scope

During the election night, I inspected the following websites:

valgresultat.no, the official results page by Valgdirektoratet (the electoral directorate)
NRK.no's dashboard, created by the state-owned public broadcast
VG's dashboard, a popular privately-owned newspaper
Aftenposten's dashboard, another popular private newspaper
Note: I don't currently work with/have a relationship to these companies, I picked their dashboards because they're popular websites and the first ones that up when I looked for the election results.

And paid attention to:

Screen reader (VoiceOver) behavior
Focus order and keyboard interaction
Visual elements such as color contrast
Semantics, labels, names, and ARIA best practices
Understandability of the data and interactions
Chart controls

For client work I would test and review these areas in-depth, each with their own set of criteria, relate them back to WCAG where relevant, and also assess how the page frame and other elements on the page influence the chart accessibility.

For this article, however, I mainly focused on finding examples that:

Illustrate some of the important dataviz accessibility best practices, or
Highlight common or interesting accessibility mistakes, or
Explain certain accessibility concepts

And to not overcomplicate the article, the websites were only tested in Safari and with VoiceOver.

Now, let's dive into some of the findings 👇🏻

Data visualizations require accessibility work

When it comes to web accessibility, writing semantic HTML will get you a long way already.

For example, if you develop a website and do things like picking <button>s for buttons, adding alt text to your images, structuring your content with heading elements (eg: <h1>, <h2>), then you have already started the work of making your website more accessible.

It won't necessarily be WCAG compliant or lead to a good and equal experience for disabled people. Typically more accessibility work is needed for that (and not just from the development side), but it does create a solid base. For example:

<button>s can by default be activated by clicking them, pressing enter (key down), or releasing space (key up).
alt="..." text on an <img> elementgives blind people and those with low vision (and others using assistive tech like screen readers) a description of the image and access to the same info.
<table>s come with their own screen reader navigation: when testing with voice over, I can use cmd + shift + up/down/left/right to move the screen reader focus/cursor between the cells in both dimensions.

With dataviz accessibility, however, the situation is a bit different.

Most visualizations are built using <svg>s. With SVG, we use elements like rectangles, circles, or paths (<rect>, <circle>, <path>) to build our visualizations. Those elements carry no semantic meaning to assistive technologies, and come with no out-of-the-box keyboard interaction. The same is true when building visualizations from <div>s and <span>s.

Data visualizations typically are inaccessible by default. If we don't actively curate accessibility of our charts, we will end up with visualizations that are varying levels of inaccessible.

Graphical elements that carry meaning need text alternatives

Let's take a look at this chart from Aftenposten:

Video in the original post

Video description: Bar chart showing the shift in votes for each party compared to last elections. The category labels (logos of the parties) are displayed vertically. If a party has a negative shift, the bar is displayed on the left side, positive shifts to the right side. I'm using VoiceOver on the page, and the only items on the chart that are reachable by screen reader are the values next to the bars, but not the party names.

The only thing read out are the text elements (<text>) which contain the numbers.

The logos are added as an SVG element consisting only of <path>s, which by default do not contain any info for screen readers to parse. As a result, only the result numbers are announced, not the parties they correspond to.

This makes the entire chart inaccessible to screen reader users. It's just a sequence of unlabelled numbers.

We may need to provide additional context and structure to the data to make it screen reader accessible

Let's take this example is from VG.

Here the screen reader announces all the images and text elements (in itself this is fine), but there is no extra info about what the numbers represent, how they relate to the images, or how the parties are structured.

Video in the original post

Video description: Comparison/progress chart showing how close the red coalition and blue coalition are to the 30 mandate majority. A screen reader is used to navigate between the different text elements of the chart, which are announced in the following order: left candidate picture alt text, the candidate name, party, amount of mandates on the left, the label "30 mandates", amount of mandates on the right, a list of text labels that just contain party abbreviations ("R", "MDG", "V") from left to right, right candidate picture alt text, the candidate name and party.

Visually, we have:

The left / red parties, on the left side of the graph
The right / blue parties, on the right side of the graph
Name, party, and picture of the main person on either side
Total amount of mandates for either side, written next to the name
How close either side is to the 30 mandate majority
Underneath each side (red/blue), which parties belong to them
The amount of mandates for each of the parties

The screen reader announced, in this order:

Image description of the candidate on the left
First name, last name, party of the candidate on the left
Mandates of the left (without label, eg. just "27")
"30 mandates"
Mandates on the right (again without label)
Initials of all the parties, from left to right
The full name, party, image description of candidate on the right

Without any of this data being structurally grouped, and without any additional labelling, this doesn't tell us the same as the visuals.

We're not told any info about the size of the parties or which side they belong to, and the number of mandates for the right side is not announced along side its label (the candidate name and picture).

Some of the following could be done to improve this:

Grouping and/or connecting the candidate name, party and amount of mandates. This includes tidying up the order of the elements. Eg: "Raymond Johansen, AP: 28", "Eirik Lae Solberg, H: 30"
Grouping the parties by left/right side, and labelling each side. Eg: "Red block" (unordered list) and "R" (list item), "SV" (list item), etc.
Adding the amount of mandates to each of the parties. _Eg: "R: 4 mandates", "SV: 6 mandates" _

The chart is interactive, and parties can be toggled on/off to see how many mandates each side would have, and how that changes who has the majority of mandates. Those updates are communicated visually, but screen reader users also need to know:

Which of those parties are toggled on/off when going through the visualization of the parties and their amount of mandates
What the tick boxes are meant for (a label to explain their purpose), and also that the visualization updated after (un)ticking a box

Not testing visually hidden labels can lead to incomprehensible data

A mistake I often come across in reviews is improper labelling elements.

Sometimes people do indeed add screen reader alternatives, but either use the wrong properties, or add information that's incorrect or not useful.

Often those type of issues happen because if you don't use assistive technology yourself, you won't notice the content and behavior of visually hidden labels until you inspect the code, test the page with a screen reader, or otherwise try to assess the accessibility.

One of the charts where I suspect this type of testing was lacking is this distribution graph by Aftenposten.

Video in the original post

Video description: The screen reader focus is moved down a list of cities. For each city, the percentage of mandates each party has is visualized, and grouped by coalition. All the cities are announced as links with the following label: "Trondheim, 100% opptalt, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn".

It shows the distribution of mandates (per party, grouped by left/right coalition) for all of the major towns in Norway, all the parties were aria-labelled by (I assume) their placeholder text: "Parti navn" aka "Party name".

As a result, VoiceOver announced results like: "Trondheim, 100% opptalt, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn, parti navn".

One of the other things that's missing here as well is, again, the number of votes connected to each party.

Some issues can always go past us for several reasons (everyone I know in tech is overworked and tired), but to me, bugs like these potentially highlight an issue with (or a lack off) accessibility processes, because:

Accessibility linters may or may not pick up on some of the issues connected to this
Code reviews (by team members that are accessibility-aware) increase the chance of these getting caught early
An accessibility focus in the content review process can discover issues with the alt text
Testing features with a screen reader would definitely flag these

So if those exist in production, it means that either the team isn't doing some/any of the above in their process, or they do a fair share of accessibility testing, but don't get the time to actually fix the issues that were raised.

Graphical elements require 3:1 contrast with the background

Most of the news media did actually fine when it came to the color contrast of the text. The main body text was black on a white background (or light text on a dark background in dark mode).

The text elements within the data visualizations generally had sufficient (4.5:1) contrast with their background as well, although there were a few hiccups.

For example, Aftenposten's green and red text showing the shift between now and the last election does not have enough contrast against white. But overall, the text color contrast requirement seemed well understood.

Things like bars on a bar chart, lines on a histogram, icons, and other graphical elements require a contrast ratio of at least 3:1 to make sure they're accessible to folks with low vision.

This was something most of the charts didn't accommodate for.

Aside from Valgresultat, all dashboards went for colors similar to the party's brand colors in their charts. That's good for cognitive accessibility, since people may recognize those already.

Some of those party colors are light, and for those NRK changed the font color for the overlaying text is changed to be at least 3:1 with the party color. That's good, and really improves the readability of those icons.

However, the same brand colors are used on the bars, which are graphical elements that require 3:1 contrast with the background. For example, SP's light green (#BBCB4D) has a color contrast of 1.79:1 against the white background, which is too low.

Additionally, all the dimmed versions of the brand colors (that visualize the numbers from last election) lack color contrast agaisn the white background.

The other newspapers had similar contrast issues. The bright green and yellow that Aftenposten used had less than 3:1 contrast with the white background, and VG's blue was at 2.63:1 too low to be used for both the text and chart elements.

The page itself needs to be accessible too

It's great if a visualization is accessible, but if it exists within a page filled with accessibility issues, then people may not even reach the chart at all.

Heading levels are important for explaining the structure and relationships of the content

Using subtitles/headings on a page introduces, structures, and sometimes summarizes the content. The text sets the expectation of what you're about to read, and the styling (font-size, weight, position, etc) of the headings says something about the relationship they have to each other.

Semantically, this structure and relationship is communicated by using heading elements with the correct heading level (<h1>, <h2>, <h3>, etc).

Valgresultat used an <h1> for all of their subtitles, not just the main page title. This took away the structure for screen reader users, and announces the page title on the same level as the subtitles in the footer, for example.

In comparison, VG added headings to each of their sections, and the heading levels reflect the structure of the page. When browsing the headings menu in VoiceOver, I can tell that "Kampen om storbyene" ("The battle for the big cities") has information for 6 different places: Oslo, Bergen, Stavanger, Trondheim, Kristiansand, and Tromsø.

Internationalization needs to be considered

Valgresultat has a language selector which lets the user switch between four different languages:

English
Norwegian (Bokmål)
Norwegian (Nynorsk)
Northern Sami (Sámegiella)

The text on the page updates to the selected language, but the language of the page never gets updated programmatically. According to the HTML lang code, the page is in English regardless of which language is selected.

Screen readers change their language and pronunciation based on the language of the content, and translation tools can base themselves on the lang attribute as well, so it's important that the language tag reflects the language on the page.

Maps are tricky to get right, often ignored

Across my client work I notice that maps are the chart type that spark the most conversation.

Do people want to navigate them sorted by name, continent, or value? What should the default sorting order be? Should keyboard users be able to navigate around spatially to neighboring countries? How do we visualize the data of small countries? Do we allow zoom? How does that work for keyboard users? How do we visualize borders? What are the color contrast requirements for adjacent regions?

All that to say: there's a lot to be considered when it comes to map accessibility. This is clear from how the different media made their maps accessible: they didn't.

The election maps were lacking screen reader interaction, table alternatives, and informative text alternatives

Across all the websites that used maps to visualize the election results, none provided a table alternative or direct screen reader interaction with the map.

Video in the original post

Video description: A bar chart and map. The screen reader announces the text labels on the bar chart, in chronological order (but reads the letters of the party names one by one), then the zoom buttons on the map are announced, and the map itself is skipped. There is no table alternative.

VoiceOver just skipped past VG's and Aftenposten's map. The zoom buttons were announced correctly, but the actual informative content was not there.

NRK's map was turned into an image with alt text, but the alt text only described what type of info was visualized on the map, not the actual data. NRK also made some extra effort to summarize the graph for everyone. Underneath the map they listed the parties and in how many municipalities they were in the majority.

Video in the original post

Video description: A map that's announced as a figure, and a text alternative is announced. However the text just describes the purpose of the graph (it's a map of Norway with the municipalities colored in the color of the party that had the most votes there). There is no table alternative. There is a list below the map, summarizing the amount of municipalities where each party is the largest.

This in a way provides a text format of the amount of color that's observable on the map, but there is no place to view a list or table with all of the municipalities and their biggest party.

Public vs. private sector?

Before this I was curious how the graphs of the public vs. private sector performed. While I did feel like more emphasis had been placed on accessibility and compliance on the two sources from the public sector, all the dashboards I inspected had room for improvement, including those from the public sector.

Currently the Norwegian public sector has to follow 47 WCAG success criteria, the private sector 35. All websites are tested had some issues against those. A couple of examples:

VG's map did not have a text alternative (SC 1.1.1)
NRK's bar charts were lacking color contrast (SC 1.4.11)
VG's party-colored text was lacking color contrast (SC 1.4.3)
Aftenposten's positive/negative numbers were lacking text contrast (SC 1.4.3)
NRK's map used only color to convey information (SC 1.4.1)
Valgresultat's language doesn't update (SC 3.1.1)

Both with the current and upcoming regulations in mind, the Norwegian news media and government definitely have some work left to do.

Looking for an accessibility review, training, or help with dataviz accessibility?

Are you after reading this article curious about how accessible your data visualizations are? Want to onboard your team on dataviz accessibility with a training session? Or have a chat about how to incorporate accessibility work into your organization?

🙋🏻 I'm an independent accessibility specialist with an offering focused on dataviz accessibility. If you're interested in hiring me for an accessibility project or are wondering how we can collaborate, feel free to reach out through accessibility@fossheim.io.

Looking back at the past year (and a half) of accessibility work.

Sarah — Sat, 31 Dec 2022 21:25:10 +0000

Originally published on my blog.

It's the end of the year, which means time to look back at what has been and write a year in review blog post about it. Because it's been silent on my blog for a while, I decided to combine it with another post that's long overdue: a recap of my first year (and a half) of freelancing.

In 2021, after roughly 7 years of working in tech, I decided to quit my job as a senior front-end developer in favour of starting my own company and work as an independent consultant. It was a scary decision, but has absolutely proven to be the right one.

Work

While having to find your own clients and plan your own work is one of the things that makes freelancing scary, it also has allowed me to find projects that are much more in line with my skills and interests.

I've gotten to work on some really interesting projects the past year and a half, including the following:

Contributed with accessibility reviews and guidelines to the WHO Data Design Language, for which I was part of Truth & Beauty's team.
Accessibility and front-end consulting for a long-term and repeat client: I assist with fixing accessibility bugs, implement and review new features, and help build internal accessibility documentation and knowledge.
Performed accessibility reviews for different products and websites. For example, I audited on all of FINN.no's data visualizations, and provided the designers and developers with guidance, documentation and tools to implement the fixes and make improvements. I also reviewed all of the State of JS and State of CSS graphs, based on Chartability.
Accessibility talks and training: including at SHOW conference, FINN.no UX Design Evenings, Little Miss Robot's Product Design Meetup (hosted @ my old university, almost felt like being back in school), and more. I also started doing internal accessibility training, office hours, and Q&As with some clients.
Wrote an essay on screen reader accessible data visualizations as part of The Urban Institute's Do No Harm Guide on Centering Accessibility In Data Visualizations. The report has 9 different essays by different folks in the dataviz accessibility field.

I also implemented a whole lot of new features across projects. Most of those were written in React and TypeScript, but I also had a couple of fun projects that combined Eleventy/Sanity as well.

Accessibility Observations

1. Many people actually do want to prioritize accessibility.

Throughout my career (almost 10 years at the time of writing this post) I've frequently come across people who just refused to care about accessibility. My main experience was always having to advocate hard for it.

I remember leaving a comment about changing a

(with a clickhandler and styled like a button) to an actual on a PR and the developer refusing to address it because they felt accessibility wasn't important enough. Or another time having to justify myself to a manager for spending time on making a color scheme more accessible. The conversation with him took longer than the actual work.

However, the past year and a half I've mainly come across the opposite: people who are looking to improve their accessibility skills, who ask a lot of questions, and who are excited to deliver an accessible quality product from the start, rather than moving fast and breaking things.

2. The tech industry faces a lot of accessibility blockers.

The enthusiasm for accessibility work doesn't necessarily translate into accessible products, though. One of the most asked questions I get after talks is still some variation of "how do I convince my boss to let me work on accessibility?" (and a blog post about this is coming soon™).

But when talking to project managers, I also often hear similar struggles: they're trying to plan around a deadline someone else has set or work within a budget they didn't decide on.

Amongst the type of companies that contact me are also design agencies and consultancies, where the time and money the team can spend on accessibility work also depends on the budget they received from their clients.

On top of that, I feel like there are a lot of accessibility knowledge gaps in the industry. Bootcamps and college degrees don't always touch upon the topic, so not everyone enters the workforce knowing about it. Learning new skills also takes time and energy, and if you want to follow a course or book, also money. Doing this after work and out of own pocket isn't achievable for everyone (and shouldn't be the expectation), but how much learning can be done on the job really depends on the company.

Long story short: there are a a lot of things that may block accessibility efforts, even if we have good intentions or come prepared. We can't necessarily control our circumstances, but we can control how we prepare for them and respond to them.

3. Accessibility bugs are more often caused by broken processes than broken code.

Yes, a lot of accessibility issues are caused by how the code is written (or how the product is designed), but the fact that inaccessible features make it into a live version that's released to users, that's typically an issue with our processes.

Most people do some sort of quality control of their products before pushing them out. Depending on the size of the company or poject that could be anything from a designer taking a quick look at what the developer built, or a detailed process involving multiple code reviews, and automatic and manual tests.

Some of the most common issues I come across are:

Missing or unclear alt text. Missing alt text can be picked up by linters, unit tests, and automatic testing tools such as Axe and Lighthouse. It can also be viewed in the browser through the inspector (developer tools), or by using a screen reader on the page.
Divs used as buttons, without the appropriate roles, labels, or keyboard controls. Most issues related to semantics will be flagged by linters and automatic testing tools, but this is also something that can be flagged in code reviews. The behavior can be tested manually by using the keyboard in the browser.
Elements disappearing/blocking the view when zooming in. This can be tested during and after development by zooming in to the browser when doing manual tests. Designers can also document how the page should behave on zoom/resize.
Lack of color contrast. This can be tested by design tool plugins (eg. Able, Stark), automated testing tools, and web-based color contrast checkers.

If a lot of those bugs are created while building, it can be an indication the team needs accessibility training (or hire more accessibility-focused engineers/designers). But if they make it into production, in my experience it usually means one or more of those things:

There wasn't enough testing/quality assurance in general.
The testing and quality assurance didn't include accessibility.
Accessibility issues were flagged, but fixes deprioritized.
Fixes for the bugs were prioritized, but no one's available to fix them.
There's no way to discover or track accessibility issues.

4. Progress over perfection: small improvements can go a long way.

It's not always possible to fix all accessibility issues a website has at once, and we may not alwyas find the best solution on the first or second try. If we try to fix everything in one go, we risk ending up fixing nothing at all.

If there's a limited accessibility budget, it can be more productive to do a high-level review of the product and help the team understand how to fix and prevent the issues, rather than holding out from doing anything until someone wants to set resources aside for a full in-depth WCAG audit (which may never happen).

Some of the "smallest" accessibility issues to solve can also be some of the largest blockers. I've come across menus where each menu item was labelled "image" and none of the pages had unique titles. From a technical point of view, that's a small mistake with an easy fix (add a text label to the icons). But for screen reader users this made the app unusable.

The more of those seemingly small issues get fixed, the deeper the conversation around accessibility can be, and the more useful user feedback can be collected.

Looking into 2023.

I'm mainly hoping to continue what I started in 2023: do a good mix of projects, with a focus on accessibility. That means front-end/accessibility consulting work, accessibility reviews, documentation, and training. I especially want to streamline and strengthen my auditing and training offering.

I have also set time aside for building accessibility tools for my company to start using (stay tuned 👀), and am also planning on writing and building in the open a whole lot more.

For example, I'm currently building a customizable links page:

Preview: links.fossheim.io
GitHub repo

I genuinely had a good year in 2022. I got to spend a lot of time with my wife and dogs, recovered from burnout and CPTSD, and had a fully-booked year of interesting clients. I hope I'm not jinxing it by writing this post, but I wouldn't mind another year like this ❤️

Happy New Year!

Building an accessible theme picker with HTML, CSS and JavaScript.

Sarah — Wed, 21 Dec 2022 18:42:19 +0000

This post was originally posted on my own blog over @ fossheim.io.

In the recent refresh of my website’s design I implemented different theming options. It’s now possible to choose between six different color schemes when reading my blog.

The need for more than just a light theme and dark theme came from the fact that personally, when I get bad migraines and headaches, low contrasting colors feel easier on my eyes, so I wanted to at least add a dark low-contrast option in addition to a regular light and dark theme.

Once the support for the first two themes was added, providing more options became really straightforward, so it was easy to let myself have some fun creating different themes!

I’ve received a lot of positive feedback on the theme switcher, and implementing light/dark modes and high contrast themes has been a recurring accessibility task across several of the projects I’ve been involved in, so I figured it was time for a write-up on how to implement a theme switcher like this.

In this tutorial, we’ll use:

HTML
CSS
JavaScript (vanilla)

What we’ll be building

At the end of this tutorial, we'll have an example with four different themes that can instantly be activated through a group of toggle buttons in the interface, and our choice will be remembered through localStorage.

You can find the final code on my theme-switcher GitHub repo, and all the demos used in this tutorial are bundled in a Theme Switcher collection on my CodePen as well.

Variable styling with CSS.

Let's start by getting our CSS ready to support themes.

We’ll need to use CSS variables (or custom properties) to make changing out colors across components easier.

Let's say we start with a CSS file that looks like this:

body { 
  background: linear-gradient(#A4F3A2, #00CC66);
  color: #034435;
} 

.callout { 
  background: #034435; 
  color: #A4F3A2; 
} 

.footer { 
  background: #A4F3A2;
  border-top: 2px solid #034435;
}

We can add a custom data attribute on the html:

<html data-selected-theme="pink">
  ...
</html>

And use that to overwrite the colors for each theme. If we continued with the CSS from above, without adding variables, we'd have to do something along these lines:

/* variables.css */
body { 
  background: linear-gradient(#A4F3A2, #00CC66);
  color: #034435;
} 

.callout { 
  background: #034435; 
  color: #A4F3A2; 
} 

.footer { 
  background: #A4F3A2;
  border-top: 2px solid #034435;
}

/* pink.css */
[data-selected-theme="pink"] body { 
  background: linear-gradient(#DFB2F4, #F06EFC);
  color: #463546; 
} 

[data-selected-theme="pink"] .callout { 
  background: #463546;
  color: #DFB2F4;
}

[data-selected-theme="pink"] .footer { 
  background: #DFB2F4;
  border-top: 2px solid #463546;
}

For a small tutorial example this might still seem like a feasible approach, but it would become really difficult to keep track of over time. The larger the website or component library, the more properties we'd need to remember to manually overwrite for each new theme. So in come ✨ CSS variables ✨, which we can set on :root like this:

:root {
  --color-background: #A4F3A2; 
  --color-text: #034435; 
  --color-accent: #00CC66;
}

We can then use those variables everywhere else in the CSS.

body {
  background: linear-gradient(
    var(--color-background), 
    var(--color-accent)
  ); 
  color: var(--color-text); 
}

.callout { 
  background: var(--color-text); 
  color: var(--color-background); 
} 

.footer { 
  background: var(--color-background);
  border-top: 2px solid var(--color-text);
}

This means that instead of having to update the styling of each element individually, we can now limit ourselves to only overwriting the variables that are defined in the :root :

:root {
  --color-background: #A4F3A2; 
  --color-text: #034435; 
  --color-accent: #00CC66;
}

[data-selected-theme="pink"] { 
  --color-background: #DFB2F4;
  --color-text: #463546;
  --color-accent: #F06EFC;
}

This looks a lot tidier already! 🥳

We can now relatively quickly scale up the amount of themes we support, without having to change anything inside the individual components.

:root, 
[data-selected-theme="green"] { 
  --color-background: #A4F3A2; 
  --color-text: #034435; 
  --color-accent: #00CC66; 
}

[data-selected-theme="blue"] {
  --color-background: #55dde0;
  --color-text: #2B4150;
  --color-accent: #00D4E7;
} 

[data-selected-theme="pink"] { 
  --color-background: #DFB2F4;
  --color-text: #463546;
  --color-accent: #F06EFC;
}

[data-selected-theme="orange"] {
  --color-background: #FA7D61;
  --color-text: #1E1E24;
  --color-accent: #F3601C;
}

Here, we have written the CSS support for our different themes, and we can switch between them by manually updating the data-selected-theme property on the body of the page to our different theme class names.

Now we will need to create a component that lets us switch themes directly from the UI instead.

Creating a theme selector component in HTML.

There are several ways you could go about implementing theming like this. For example, GitHub has a place in the setting where it’s possible to select a color theme by using radio buttons.

I decided to go for a group of elements. It’s how I designed them visually, so it makes sense to match that pattern in the semantics.

Léonie Watson has an excellent article explaining why an element’s visuals and semantics should match, but in short: different elements (buttons, radio buttons, links, etc) have their own keyboard and screen reader controls, and we want to make sure the actual interaction available lines up with the user’s expectation.

Communicating the selected theme.

Now we have our buttons, but we don’t have anything in place yet to indicate which theme is selected. We’re using the green by default, so we can already pre-select that button by adding aria-pressed="true".

<div class="theme-switcher">
  <button aria-pressed="true">Green</button>
  <button aria-pressed="false">Blue</button>
  <button aria-pressed="false">Pink</button>
  <button aria-pressed="false">Orange</button>
</div>

The aria-pressed tells assistive technology whether or not a button is checked. For example, VoiceOver will read the above selected button as:

*Green, selected, toggle button
*

We can use the same aria-pressed property in the CSS to style the selected button differently:

button[aria-pressed="true"] { 
  background: var(--color-text);
  color: var(--color-background);
}

Updating the selected theme with JavaScript.

So now comes the fun part: making the buttons interactive using JavaScript. When we activate a button (using click, space, or enter), we want:

The class name on the body to update with the corresponding theme.
The button’s aria-pressed property to be set to true.
All other theme buttons to be toggled off (aria-pressed=”false”).
The choice to be saved for next time we visit the page.

Reacting to button clicks.

We’ll first need to detect which button has been clicked. We can do so by selecting all the theme buttons on the page, and then looping through them and adding a click event listener to each of them.

/* Logs the clicked button */
const handleThemeSelection = (event) => {
  console.log('button clicked', event.target);
}

/* Selects all buttons */
const themeSwitcher = document.querySelector('.theme-switcher');
const buttons = themeSwitcher.querySelectorAll('button');

/* Adds the handleThemeSelection as a click handler to each of the buttons */
buttons.forEach((button) => {
   button.addEventListener('click', handleThemeSelection);
});

Because we used the element, the click event will also be called when using the space and enter key to activate it.

Adding theming info to the buttons.

If we interact with the buttons on our page, we’ll notice that we can indeed detect the selected element this way.

But it doesn’t give us much we can use in the code to update the themes. So before we continue, now is a good time to add some more custom properties to our HTML.

<div class="theme-switcher">
  <button data-theme="green" aria-pressed="true">Green</button>
  <button data-theme="blue" aria-pressed="false">Blue</button>
  <button data-theme="pink" aria-pressed="false">Pink</button>
  <button data-theme="orange" aria-pressed="false">Orange</button>
</div>

Updating the theme.

Now we can actually target the data-theme value in our click handler:

const handleThemeSelection = (event) => {
  const theme = event.target.getAttribute('data-theme');
  console.log(theme);
}

And use it to update the data-selected-theme property programatically. The following code will be enough to get the color scheme to update:

const handleThemeSelection = (event) => {
  const theme = event.target.getAttribute('data-theme');
  document.documentElement.setAttribute("data-selected-theme", theme);
}

const themeSwitcher = document.querySelector('.theme-switcher');
const buttons = themeSwitcher.querySelectorAll('button');

buttons.forEach((button) => {
   button.addEventListener('click', handleThemeSelection);
});

If we click on the different options now, the styling of the page indeed updates, but the state of the buttons is still unchanged. Even if we select the pink theme, the default green options still is shown as active instead.

Updating the button properties.

We need to reflect this change in our button group as well. When clicking a button, we can set its aria-pressed attribute to true:

target.setAttribute('aria-pressed', 'true');

This will select the newly clicked button, but still won’t update the aria-pressed value of whichever color themes were selected previously, meaning several buttons can be selected at the same time.

To fix this we'll want to reset all aria-pressed buttons to false. Before updating our clicked button's value, we can first select the button that was still active:

const prevBtn = document.querySelector('[data-theme][aria-pressed="true"]');

And then set aria-pressed to false:

const prevBtn = document.querySelector('[data-theme][aria-pressed="true"]');
prevBtn.setAttribute('aria-pressed', false);

Because we targeted [aria-pressed="true"] to style our selected state, we don’t need to do anything else to update the styling.

Saving the choice.

Our theme selector works! 🥳

The final step will be to remember our choice, so we don’t need to re-select the theme each time we visit the page.

Updating the local storage.

We can save the user selected theme in the local storage using the localStorage.setItem() function when clicking the button.

const handleThemeSelection = (event) => {
  const theme = event.target.getAttribute('data-theme');
  document.documentElement.setAttribute("data-selected-theme", theme);

  const prevBtn = document.querySelector('[data-theme][aria-pressed="true"]');
  prevBtn.setAttribute('aria-pressed', false);
  event.target.setAttribute('aria-pressed', 'true');

  localStorage.setItem('selected-theme', theme);
}

On page load, we can then check which theme has been stored in the local storage by calling:

const savedTheme = localStorage.getItem('selected-theme');

If a theme has been saved, we'll need to:

Unselect the default selected button
Select the button that matches the saved theme
Change the data-selected-theme to the saved theme

In order to avoid performing unnecessary actions, we'll only execute this code when the saved theme is different from the default theme:

const savedTheme = localStorage.getItem('selected-theme');
const defaultTheme = "green";

if (savedTheme && savedTheme !== defaultTheme) {
  const prevBtn = document.querySelector('[data-theme][aria-pressed="true"]');
  prevBtn.setAttribute('aria-pressed', false);

  document.querySelector(`[data-theme="${savedTheme}"]`)
    .setAttribute('aria-pressed', true);

  document.documentElement
    .setAttribute("data-selected-theme", savedTheme);
}

Code cleanup

There is still some repeated code. The way the aria-pressed and data-selected-theme are updated after loading the page and after clicking a button is more or less the same. So we can move this part into its own function.

const applyTheme = (theme) => {
  const target = document.querySelector(`[data-theme="${theme}"]`);

  document.documentElement
    .setAttribute("data-selected-theme", theme);

  document.querySelector('[data-theme][aria-pressed="true"]')
    .setAttribute('aria-pressed', 'false');

  target.setAttribute('aria-pressed', 'true');
};

The same function can then be called when clicking an option (from within handleThemeSelection), and when loading the page.

const handleThemeSelection = (event) => {
  const target = event.target;
  const isPressed = target.getAttribute('aria-pressed');

  /* if clicked theme is different from current theme */
  if(isPressed !== "true") {
    const theme = target.getAttribute('data-theme');        
    applyTheme(theme);
    localStorage.setItem('selected-theme', theme);
  }
}

const savedTheme = localStorage.getItem('selected-theme');

/* if saved theme is different from current theme */
if(savedTheme && savedTheme !== defaultTheme) {
  applyTheme(savedTheme);
}

Final result

And done! We have a basic theme switcher, that works with keyboard navigation and screen reader!

Resources

The code for this tutorial is available through my theme-switcher GitHub repo, and all the demos used in this tutorial are bundled in a Theme Switcher collection on my CodePen as well.

I'd love to see the result if you end up using my tutorial to add a theme selector to your website 🎨✨

Like my content? → Subscribe to my newsletter or my RSS feed.

Want to collaborate? → I work as an independent consultant, open for new projects.

I drew a synthesizer with HTML & CSS

Sarah — Sun, 04 Apr 2021 22:42:26 +0000

I made a new drawing using only HTML & CSS. This time I chose to go for the Muson toy synthesizer. I've been wanting to draw it for a while now, so I'm glad I finally got to do it.

Tutorials: https://fossheim.io

Patreon: https://patreon.com/fossheim

Buy Me A Coffee: https://buymeacoffee.com/fossheim

Other CSS drawings I've made:

How to create a screen reader accessible graph like Apple's with D3.js

Sarah — Tue, 23 Mar 2021 13:38:07 +0000

Originally posted on fossheim.io.

After previously writing about the accessibility of Apple Health’s data visualizations, I felt inspired to recreate one of them with D3.js. I already covered some of the basics in the form of a bar chart, so this time I decided to go for a different type of graph: the activity rings.

Before we start

While we will build the graph together step by step, this tutorial does require some previous knowledge or experience with D3.js. If you haven’t used D3 before, I suggest starting with some of these tutorials:

Part 1: Drawing the rings.

First, we’ll need to add a container in the HTML, and (optionally) style the page with CSS already. Next, we’ll draw an SVG element using JavaScript:

/* Define properties */
const width = 450;
const height = 450;
const margin = 40;

/* Add SVG inside <div id="activity"></div> */
const chart = d3.select('#activity').append('svg')
  .attr('width', width)
  .attr('height', height);

Now that we have an we can start adding elements to it. First, we’ll create a group to draw the rings in, and center it within its parent ().

const rings = chart.append('g')
  .attr('transform', `translate(${width / 2}, ${height / 2})`);

Then we’ll need to draw our three rings for moving, exercising, and standing. For now, we’ll be using the following input data:

const stats = [
 {
    name: 'Moving',
    value: 122,
    goal: 350,
    perc: 0.35,
    unit: 'kcal',
    color: 'hotpink'
  }, {
    name: 'Exercising',
    value: 40,
    goal: 40,
    perc: 1.00,
    unit: 'min',
    color: 'limegreen'
  }, {
    name: 'Standing',
    value: 9,
    goal: 12,
    perc: 0.75,
    unit: 'h',
    color: 'turquoise'
  }
];

There are a few different ways to draw the rings, but I chose to drawpaths in combination with the d3.arc() function by looping through the stats and using the perc (percentage) to define start and stop positioning.

rings.append('path')
    .attr('d', d3.arc()
      .innerRadius(150)
      .outerRadius(200)
      .startAngle(0)
      .endAngle(Math.PI) // full circle: Math.PI * 2
     )
    .attr('fill', 'white');

This would give us half a donut that’s 200px in radius (400px in diameter), has a band width of 50px and a gap of 2px.

When we look back at the activity rings, we can see that each ring should decrease in size, and we should have a small gap between each of the rings.

Concretely, this means that for each row of data, the innerRadius and outerRadius should get smaller.

If we set our radius to (width - margin) / 2 (so it takes up the entire space of the SVG minus a predefined margin) and the stroke/donut width to 50, the first row of data would look like this:

rings.append('path')
    .attr('d', d3.arc()
      .innerRadius((width - margin) / 2 - 50)
      .outerRadius((width - margin) / 2)
      .startAngle(0)
      .endAngle(Math.PI * 2 * 0.35)
     )
    .attr('fill', 'hotpink');

Because Math.PI * 2 gives us a full circle, we can multiply it with the goal completion percentage (stat.perc) to calculate the correct endAngle.

For the second ring, this would have to be:

rings.append('path')
    .attr('d', d3.arc()
      .innerRadius((width - margin) / 2 - 100 - 2)
      .outerRadius((width - margin) / 2 - 50 - 2)
      .startAngle(0)
      .endAngle(Math.PI * 2 * 1)
     )
    .attr('fill', 'limegreen');

Which we can generalize as:

stats.forEach((stat, index) => {
  rings.append('path')
      .attr('d', d3.arc()
        .innerRadius(radius - circleStroke * (index + 1) - circleSpace * index)
        .outerRadius(radius - circleStroke * index - circleSpace * index)
        .startAngle(0)
        .endAngle(Math.PI * 2 * stat.perc)
      )
      .attr('fill', stat.color);
});

Then, we’ll need to add a similar <path> for the darker, uncompleted part of the circle. The only thing we need to do for that is set the startAngle to fullCircle * stat.perc, so that it starts where the bright circle ends and set the endAngle to Math.PI * 2. We’ll also turn down the opacity.

stats.forEach((stat, index) => {
  rings.append('path')
      .attr('d', d3.arc()
        .innerRadius(radius - circleStroke * (index + 1) - circleSpace * index)
        .outerRadius(radius - circleStroke * index - circleSpace * index)
        .startAngle(0)
        .endAngle(Math.PI * 2 * stat.perc)
      )
      .attr('fill', stat.color);

  rings.append('path')
      .attr('d', d3.arc()
        .innerRadius(radius - circleStroke * (index + 1) - circleSpace * index)
        .outerRadius(radius - circleStroke * index - circleSpace * index)
        .startAngle(Math.PI * 2 * stat.perc)
        .endAngle(Math.PI * 2)
      )
      .attr('fill', stat.color)
      .attr('opacity', 0.25);
});

I made a few more modifications to this and moved part of the code into a drawRings function, so I wouldn’t have to repeat the calculations for the inner and outer radius. You can see the full code for this part in the pen below 👇🏻.

If we listen to this with a screen reader, such as VoiceOver or Narrator, we won’t hear much useful. In fact, we won’t hear anything at all. That is because so far we have only drawn shapes, which doesn’t really tell a screen reader what to do.

In my previous tutorial we used elements to read out the data, but for this one I decided to go for another option: the aria-labelledby property in combination with a and element. This is inspired by how FiveThirtyEight labeled their graphs in their 2020 presidential election forecast (I reviewed those graphs before).

We’ll want to:

Set the role of the graph to img.
Include a and inside the SVG, and give each a unique id.
Link the title and description to image by adding aria-labelledby=”titleID descID” to the graph.

If we want to mimic Apple’s native behavior, the completion percentage for all three rings should be read simultaneously. Eg. “Moving: 35%. Exercising: 100%. Standing: 75%“.

To generate this text, we’ll create a function that extracts the label (moving, exercising, standing) and the values (35%, 100%, 75%) from the array with the data and then puts it in a sentence.

const generateDescription = () => {
  return stats.map((stat) => {
    return `${stat.name}: ${stat.perc * 100}%.`;
  }).join(' ');
}

Here we loop through the objects inside the stats array and replace each of them with a string. So after we’re finished looping through the stats, this is our output:

[
  'Moving: 35%.',
  'Exercising: 100%.',
  'Standing: 75%.'
]

Lastly, we’ll use .join(' ') at the end to create one long description, and use the output of the function to fill out the text inside the element.

/* Create the chart. */
const chart = d3.select('#activity').append('svg')
  .attr('width', width)
  .attr('height', height)
  .attr('role', 'img') // SR support
  .attr('aria-labelledby', 'activityTitle activityDesc'); // SR support

/* Add title. */
chart.append('title')
  .text('Activity')
  .attr('id', 'activityTitle');

/* Add the description. */
chart.append('desc')
  .text(generateDescription)
  .attr('id', 'activityDesc');

Alternative: Using aria-label

We can achieve the same result by using aria-label instead of aria-labelledby in combination with the same generateDescription() function.

const chart = d3.select('#activity').append('svg')
  .attr('width', width)
  .attr('height', height)
  .attr('role', 'img') 
  .attr('aria-label', generateDescription());

Part 3: Explaining the data.

So now we have three screen reader accessible rings, but visually those don’t tell us that much yet. Pink, green and blue don’t really mean anything, and don’t work well for color blind folks either.

Let’s start by adding icons. For the sake of simplicity, I didn’t draw or import any icons but used existing symbols as text.

/* Define icons */
const icons = {
  moving: '↦',
  exercising: '↠',
  standing: '↟'
};

/* Inside of stats.forEach(...), 
  at the end of the loop */
rings.append('text')
    .text('icons[stat.name.toLowerCase()]')
    .attr('fill', '#000')
    .attr('transform', `translate(${circleSpace}, -${(arc.outer + arc.inner) / 2 - circleSpace * (index + 2)})`)
    .attr('font-size', '1.5rem');
});

In addition, we should explain what the colors and symbols mean in a legend. Apple combines this explanation with statistics that show the data in a more detailed way.

This doesn’t just add context to the colors of the graph, but also makes the same data available in different formats, which also improves accessibility.

We can implement a simplified version of this by adding elements containing the label, total, goal and percentage values. We’ll also need to add the corresponding icons and colors, and adjust the vertical position for each row.

chart.append('text')
    .text(`${icons[stat.name.toLowerCase()]} ${stat.name}: ${stat.value}/${stat.goal}${stat.unit} (${stat.perc * 100}%)`)
    .attr('text-anchor', 'middle')
    .attr('transform', `translate(${width / 2}, ${radius * 2 + 20 * (index + 2)})`)
    .attr('fill', stat.color);

The text is added directly to the , not to the same group as the rings, so that it can be focused when using VoiceOver.

Right now the icons in the legend will still be read. If we want that to prevent that from happening, we can add the aria-hidden='true' attribute to the icons this way:

const legend = chart.append('text')
    .attr('text-anchor', 'middle')
    .attr('transform', `translate(${width / 2}, ${radius * 2 + 20 * (index + 2)})`)
    .attr('fill', stat.color);

  legend.append('tspan')
      .text(`${icons[stat.name.toLowerCase()]} `)
      .attr('aria-hidden', 'true');

  legend.append('tspan')
    .text(`${stat.name}: ${stat.value}/${stat.goal}${stat.unit} (${stat.perc * 100}%)`);

Alternative: Expanding the aria-label solution

Next steps.

We can keep styling the graph to make it look more similar to Apple’s graphs, or apply our own styling to it. A few possible next steps could be to move the color scheme to the CSS file, replace the icons or add gradients and shadows.

If you’re new to working with D3.js, SVGs or (dataviz) accessibility, here are a few more articles that can help you with this:

Feel free to share the results with me (you can tag me on Twitter or mention it in the comments here) if you build something similar using this tutorial or have a different way of solving this 👀

Bonus solutions:

Different type of input.

Navigate through the activity rings.

Excluding non-binary people by design: How sign-up forms can lead to discrimination

Sarah — Mon, 01 Mar 2021 15:00:01 +0000

What happens when we don’t include trans and non-binary people in our products? How do our products cause harm? Why is education so important and change so hard?

The Markup’s discovery that Google allowed advertisers to exclude non-binary people from job and housing ads, while blocking them from excluding men or women for those ads, is a great example of what happens when we don’t include or prioritize minoritized groups in our products.

How Google allowed this discrimination to happen.

TL;DR: Careless design leads to broken features that open the door for discriminating trans and non-binary people.

When signing up for a Google account, users are given four gender options:

Male
Female
Rather Not Say
Custom

When picking the “custom” option, users can write their gender in a text box.

But advertisers only get three checkboxes they can use when picking an audience for their ads:

Male
Female
Unknown

The Markup found that everyone who picked the “rather not say” or “custom” option in their settings gets grouped within the “unknown” category for advertisers.

Image from The Markup.

While Google doesn’t allow ads to exclude men or women from jobs, housing, or financial products, they did allow advertisers to exclude the “unknown” category, leaving those outside of the gender binary excluded as well. All of this during a time where housing, jobs and financial aid are crucial for everyone, but even more so to those who are already more often exposed to discrimination and abuse.

Alienated and erased by design.

Just the way this data gets labeled already shows how much of an afterthought gender diverse people were.

As non-binary people, we first have to indicate that we’re “other” or “custom”, and then that information gets disregarded and Google categorizes us as “unknown”. First we’re alienated, then we’re forgotten about.

We should include and prioritize the needs and safety of minoritized groups, as early in the process as possible.

The data that comes out of these gender selection boxes isn’t just sitting in a database somewhere, it’s actively being used. In this case, it decides who gets to see certain ads, and Google’s lack of care for trans and non-binary people led to vulnerable groups being excluded from housing and job ads.

But data on gender is frequently collected and used, from targeted ads and demographic research to dating apps and medicine.

If we don’t include and prioritize people from minoritized groups in our design and tech practices, we risk not only collecting incomplete or incorrect data, but also processing and using it in biased and harmful ways.

Preventing this goes beyond just hiring more trans people or doing user tests with a diverse audience, though.

While trans and non-binary people would probably have flagged the potential harm behind those features, they do need to be given trust, safety and support as well.

Just recently, Google fired Timnit Gebru and Meg Mitchell from their ethical AI team because of a research paper critical of AI systems that process language. And meanwhile Amazon is paying its employees to quit as a way to block unionization efforts.

Lack of data, visibility and accountability.

As The Markup’s story pointed out as well, it’s difficult to know which ads you’re missing out on because of your gender. While we often can get information about why we’re seeing a certain ad, we can’t ask “why am I not seeing this ad?” for ads we’re not seeing, making it hard to hold companies accountable.

Similarly, if those companies analyze our data to understand what issues we’re facing on their platform but don’t have accurate data on non-binary people, they’ll easily ignore our needs.

I’ve participated in countless of employee satisfaction surveys where non-binary wasn’t an option at all, meaning the answers of non-binary folks are miscategorized. When companies then use that data to analyze what they need to improve upon, the issues that are trans and non-binary specific are lost because there simply is no data for it.

This is why data isn’t neutral or objective, but influenced by those who collect it, and later possibly further compromised by the biases of those that use it.

Preventable accidents.

It’s easy to label these inequalities as “accidental” or “unintended side effects”. But how accidental or innocent is this really? This isn’t the first example of Google (and other tech companies) causing harm to minoritized people, and it won’t be the last one either.

Even Google’s gender selection form at sign-up has received criticism for a long time (I wrote about it as well), and neither ethical design nor trans people are new concepts.

Most trans and non-binary people are all but surprised that something like this could happen, given we constantly experience the consequences of trans-exclusionary design.

As I touched upon earlier, to me this shows that either no trans or non-binary folks were involved or consulted on this (which is a lack of user research as well, aka bad design), or their concerns just weren’t listened to.

We must, collectively, be better at including and protecting minoritized groups in our designs. After all, features and data don’t exist in a vacuum. Technology is so embedded into our society that even seemingly small features can cause real-world harm.

What we can learn from Apple's dataviz accessibility

Sarah — Sun, 21 Feb 2021 17:47:42 +0000

Originally posted on fossheim.io.

Ever since getting the Apple Watch in November, I’ve been looking at my Apple Health & Activity data on a daily basis. After being disappointed by all the inaccessible graphs around the US Presidential Elections, I wanted to find out how Apple’s visualizations are handled by VoiceOver.

They’re an inspiration to many when it comes to visual design, so I was especially wondering if we can use them as an example for accessible data visualizations as well.

Daily activity breakdown

The health app has a page dedicated to activity, which visualizes movement, exercise and standing hours per day, week, month and year.

In this view, VoiceOver allows us to navigate through the graph by the hour. Each hour is a column, which includes the movement, exercise and standing values. While the labels on the axes aren’t read, that information does get added at the start of each of the columns' labels.

All the data is communicated clearly with pretty straightforward navigation. One thing I personally found inconvenient was having to keep moving along hour by hour even when there’s no data.

Video Transcript: https://pastebin.com/raw/6puRSntf.

For example, between 1AM and 9AM the values for moving, exercising and standing are usually always zero.

But on the other hand Apple’s current solution is consistent: VoiceOver reads three values for each hour in the day, no matter what.

Whether or not consecutive blocks with no activity should be grouped is more of a screen reader usability question, for which I recommend doing user tests with blind or visually impaired folks.

The Apple Watch activity breakdown provides a similar experience. The only difference is that the values aren’t grouped, and movement, exercise and standing are read as three different graphs. Each of them is broken down by the hour, and includes the timeslot and value in the label.

Activity rings

The activity rings display how far you’ve gotten towards achieving your daily goals. VoiceOver pronounces the (visually hidden) label of each bar, followed by the percentage that’s visualized.

In the Activity app, the rings seem to have a bug (or feature?!) that causes the activity to be read twice, but overall I feel like this one works quite well.

Video Transcript: https://pastebin.com/raw/3FT6r8pe

I’m personally a big fan of visualizing the same data in different formats. Not everyone processes data the same way, so providing enough alternatives makes the data both more accessible and user friendly.

ECG

I was really curious about how they’d solve something like the ECG functionality on the Apple Watch with VoiceOver, since it continuously has to update the data. But the answer is actually very logical: just like physical heart rate monitors do it, by using beeping noises that change in tone and frequency. After the ECG is finished, the result gets displayed (and read by VoiceOver) as text.

Blood oxygen

Measuring the blood oxygen also relies on sounds rather than words. There’s a beep every second for the duration of the countdown, which starts speeding up during the last few seconds. Once the timer is done, the results get focused and are browsable using VoiceOver.

Watch faces

One of the watch faces that I use a lot has several activity visualizations on it. It’s basically the same as the iPhone’s activity app, but much more compact. Unfortunately, it doesn’t always work very smoothly with VoiceOver.

The first time I tried using it, VoiceOver didn’t read the values of the activity rings and only said “Activity” with no further information. After opening the activity app and going back to the home screen, the values were read correctly.

Similarly, there are some issues with the bar chart underneath as well. The values are grouped in four six-hour intervals, which is probably because swiping through 24 hours of data on a small surface isn’t necessarily a pleasant experience. The buttons and text on the screen are also focusable by clicking on them, which is expected behavior but also tends to make navigating with VoiceOver on a bit of a challenge.

However, it’s never mentioned that these are 6-hour blocks, and VoiceOver only reads the “00”, “06”, “12” and “18” labels, which is a bit confusing.

Video Transcript: https://pastebin.com/raw/EiQN60XD.

The grouping also has a few bugs. In the example above, the standing hours that get read (2 hours, 2 hours, 6 hours, 1 hour) don’t match the visuals or text (9 dots or hours). And even though the total amount of burnt calories is 453 for the day, VoiceOver consistently reads 0 calories for each block.

Highlight cards

One last thing I appreciate in the health app are the cards that show highlights of the data. Each graph that’s displayed in those has a short summary written on top, eg. “During your last walk, your heart rate was 114–158 beats.” or “On average, you’re walking less this year compared to last year.”.

For me personally, the summary makes it quicker to get the information I need, since I don’t have to find and read labels or process any visuals at all. But it’s also a nice addition to the graphs when listening to them with VoiceOver. The goal of the graph is to get a quick summary or highlight of the data, which isn’t easily solved by swiping through a list of numbers.

The graphs in the cards were read differently for different types of graphs as well, but seemed to follow a pattern: the graph wasn’t read when it served as an illustration of what was already described in the summary, but numbers bringing more detail to the summary were included.

Apple’s graphs set a good example, so what can we learn from them to make our own visualizations more screen reader accessible?

Whether Apple’s solution would work well for our own graphs is entirely dependent on what we’re trying to visualize, who our visualizations are for and how they want to use them. In fact, I’m quite sure Apple can still improve their graphs as well. As we improve our products, we will always find new insights, and as technology changes we will also keep finding better technical solutions to the same problems.

But that’s also why I think Apple’s visualizations are good to take an example of: they have a basic level of decent accessibility that can be used to get actual feedback. The data gets read by VoiceOver, and does so in a way that makes sense. Regardless of what can be improved, the graphs are both usable and testable.

This is a big contrast with the visualizations around the US Presidential Elections I examined in November 2020, where almost nothing was accessible to screen reader users. The main feedback people will give about a graph that reads “Image” over and over again will be to at the very least add alt text. Not much can be said with regards to the data experience if the data isn’t even there.

That’s why it’s important to have accessibility included from the start. The faster the data is accessible, the faster we can test how blind folks are using the graph and what would give them an even better experience. As long as we have that plan in place, we can start small and still end up with a good and accessible solution relatively quickly.

More resources to get you started

🎙 I also give talks about dataviz accessibility. My Outlier talk (together with Frank Elavsky and Larene Le Gassick) will be published in the upcoming weeks, and I’ll also be giving an introduction to design accessible graphs at axe-con.

I launched a directory with ethical design resources

Sarah — Sun, 27 Dec 2020 23:40:11 +0000

Tech is all around us, developing fast, and not going away. Which is why ethics should be a part of the design and engineering curriculum, and a focus for everyone working in the industry.

Earlier this year I wrote about what it's like navigating the internet as a non-binary person and the harm transphobic AI can cause.

There were also stories about social media apps using facial recognition failing trans people, algorithms keeping students out of college, software that can depixelate faces, surveillance AI, fake news around COVID and the US elections, and countless more examples of tech failing the people.

This is nothing new, and should not be surprising. Tech isn't neutral. It's made by people and consumed by people. People write algorithms, collect training data, design websites, write code and prioritize features.

Countless of books, articles and even documentaries have been made about the issue, and there are plenty of resources out there that can educate us on the issues the tech industry is facing and can guide us to do better.

So I decided to build a directory that lists them: ethicaldesign.guide!

It's a growing directory of tools, articles, books, podcasts, and other learning resources to guide us in creating more ethical and more inclusive products. I'll be editing it continuously with new resources (and anyone can suggest a resource, so keep an eye out on the page or subscribe to the mailing list to receive a monthly update on new resources and interesting reading material.

Originally posted on fossheim.io

How (not) to make accessible data visualizations, illustrated by the US presidential election.

Sarah — Mon, 23 Nov 2020 17:42:21 +0000

Originally published @ fossheim.io.

In the days around the 2020 US presidential elections a lot of people have been following predictions, results and exit polls quite closely. The majority of news sources published plenty of visualizations, but very few of them in an accessible format.

Let’s take a look at some important aspects of accessible data visualizations, based on what The New York Times, CNN, FiveThirtyEight, The Guardian and Fox News are doing right and wrong.

Screen reader support

The main visualizations across all news sources are the electoral college votes for each candidate, and a map showing the results per state.

Most of these graphs are built either using the <canvas> element or SVGs (Scalable Vector Graphics), which both require a bit of extra work to be made accessible. When not keeping accessibility in mind, things like this might happen.

This is an example from The Guardian (using Safari on iPhone), where VoiceOver reads every state on the map as “image”.

Read all the data

One option to improve a graph like The Guardian’s is to add the state name and results to each focusable element of the map by either adding visually hidden labels or using the aria-label property (or alt tags when dealing with images).

The New York Times takes this approach with their graphs showing the percentage of votes each candidate got, but not in an accessible way.

VoiceOver reads through the labels on the x and y axis, and the percentage of votes, but not who those votes belong to full audio transcript.

Adding an extra "Biden" and "Trump" (or "Democrat" and "Republican") label to the numbers would solve this issue, and also add more visual context.

Fox News has a similar issue on their electoral college votes progress bars. The main progress bar for each candidate is built by grouping smaller bars representing the states they won.

Visually, it’s rather easy to distinguish between the two candidates’ votes. However, VoiceOver does not make any difference between them at all.

Instead, the only information it reads is one long sequence of numbers along the lines of "3 votes, 14 votes, 7 votes," etc (full audio transcript). So the context of how many votes belong to Biden, and how many to Trump, gets lost entirely.

<div class="bars">
    <div class="bar dem state-va">
        13 votes
        <div class="bar-tooltip" style="display: none;"> 
            <div class="name">Virginia</div>
            <div class="value">13</div>
            <div class="party">Declared Democrat</div>
        </div>
    </div>
</div>

There's not much they would need to do to give the "13 votes" some more context for asssistive technology, most of the code is already there. Removing the display: none; property and instead visually hiding the tooltip would allow screen readers to read "Virgina, 13, Declared Democrat".

Link to an accessible data table

Another option for the Fox News graph is to only read the total number of votes and link to an accessible table for the breakdown instead. That link could be provided in a caption, description or alt text, depending on the format of the graph. This is similar to how complex images are treated.

But it's also important to remember that while a table might make the data available for people using screen readers, it doesn't necessarily provide a good experience. The user still has to the table, and also misses out on context a graph provides.

Give data a human voice by using titles and descriptions

In their election forecast, FiveThirtyEight takes a different approach from most other sources.

Let’s take the outcome simulations as an example. These are split into two different visualizations, a red one for Trump and a blue one for Biden.

The x-axis shows the amount of electoral votes, and the y-axis the amount of simulations in which the candidate gets that amount of votes. The length and position of the bars tells us which candidate is more likely to win according to their simulations. There are a lot of blue bars on the right side of Biden’s graph, which means he won in most of their simulations.

Since the exact numbers aren’t as important here, VoiceOver doesn’t read or link to them and instead reads a summary of what’s displayed. In this case, it says Trump won in 10% of the simulations and Biden won in 89% of them full transcript.

<svg class="svg" role="img" aria-labelledby="title-biden desc-biden">
    <title id="title-biden"></title>
    <desc id="desc-biden">
        Electoral college vote distribution for Biden,
        who wins in 89.2% of simulated outcomes.
    </desc>
    ...
</svg>

This method works really well for FiveThirtyEight’s type of data. It doesn’t matter in exactly how many simulations Biden got 300 electoral votes, what matters is that in the majority of simulations he won the presidency.

Unfortunately, the graphs aren’t keyboard accessible, and sighted people still get access to more details than those using assistive technology.

And while on Mac using VoiceOver their solution provides a much better experience than most other election visualizations, it's also not fully accessible across platforms and browsers. When for example using Edge on Windows, Narrator does not read the title and description of the graph.

Keyboard navigation

When graphs are interactive, keyboard navigation should be taken into consideration as well.

For example, some graphs show more information or filter data when clicking or hovering. It should also be possible to achieve this without a mouse or trackpad, using only the keyboard. Almost none of the election graphs provided this functionality.

When using Chrome on Mac with VoiceOver, the electoral map from ABC did make it possible to navigate through the different states using the arrow keys.

But it’s also important to note that this isn’t something that works across all screen readers or browsers. Safari and FireFox on Mac had a less optimal experience and on iPhone the navigation didn’t work at all.

And as Frank Elavsky explains really well on Twitter, there are a lot of problems with both VoiceOver and keyboard navigation with NVDA (Windows) on Chrome and IE.

Accessible colors

Color is another important aspect to keep in mind when designing data visualizations. Not enough color contrast can make visualizations and text hard to read, and only relying on color can make the experience for color blind visitors very confusing.

This is a simulation (Monochromacy/Achromatopsia) of The New York Times their main map. Suddenly it's no longer possible to tell which states are Democrat (originally blue) or Republican (originally red):

Patterns can be used in addition to colors, although depending on the type of graph and amount of different colors that can become quite distracting.

Very busy visualizations aren’t accessible either, so an alternative is to pick colors with high contrast, or adding additional text labels with context. For example, this map could also have either the candidate or party names listed in addition to the state name.

Brightness

Another important factor to keep in mind is the brightness or intensity of the color. Very bright colors affect readability, and also make it much harder to focus. For some users it can also cause anxiety or pain.

CNN uses a very bright variation of red and blue throughout their election results page. In addition, they also use a relatively bright yellow to label the battleground states in some of their tables.

Make data easy to find and understand

Accessibility and usability go closely together. Making data visualizations accessible isn’t just about meeting the technical requirements or making them compatible with assistive technology. It also means making them easy to understand for everyone. Everyone consumes information differently, which is something important to keep in mind.

Adding explanations or conclusions in clear language can be beneficial for people with anxiety, while dyslexic people might prefer visuals over numbers.

FiveThirtyEight’s election forecast does a pretty good job at explaining their graphs. Each graph has a title and description with context, and most of them have a side note with more information about the data or type of visualization.

Two FiveThirtyEight election forecast simulations: Electoral college vote distribution for Trump, who wins in 10.4% of simulated outcomes. And Electoral college vote distribution for Biden, who wins in 89.2% of simulated outcomes.

On top of that, the graphs also have more labels and explanations directly where relevant. The outcome simulations don’t just show the numbers, they also have labels that indicate which candidate is more likely to win. They also highlight some important points, for example the 270 electoral votes threshold.

The Guardian has cards for each of the key states to watch that contain a map, the vote count and breakdown, and an explanation for why the state is important to the election. They were one of the few sources that had an overview like that per state without hiding it behind hover functionality.

At the same time, these cards do contain a lot of information and text, and they all end up looking more or less the same. While the colors are not as bright as those in CNN’s graphs, the view still becomes a bit too cluttered and can be painful on the eyes.

The electoral college votes play a big role in the election. Getting to that information easily is crucial, especially as more results come in and people start calculating which scenarios can still happen. The Guardian’s cards do provide that information, although it gets a bit lost in between all the other content.

The Guardian, and CNN, have the same information available when hovering over a state on their map as well, although not in a keyboard or screen reader accessible way.

The New York Times has a separate map for the electoral college votes, where each state is represented by a number of circles representing the amount of votes. While it visualizes the distribution of votes more precisely than a regular map, it doesn’t write out the number anywhere in an accessible way.

The only map that has the numbers available without needing to hover is Fox News. They write the number of votes underneath the state name. For the states that are too small, they write the number of votes next to the map. This is an easier way of getting the exact number than the other news sites provided, and could even be combined with The New York Times map.

Unfortunately, the map from Fox news isn’t screen reader accessible either. VoiceOver reads the entire map as an image without alt text, and then just moves on to the next section. And while they kept the map relatively clean, there's still a lot going on visually (that white text on the bright red background, for example), which in combination with the legend not being easy to spot can feel overwhelming for some as well.

How to continue from here

If you’d like to learn more about making graphs like these accessible, I suggest to start by reading the following resources:

Or if you want to learn more about accessibility in general:

If you like my work, consider following me on Twitter, becoming a patron or buying me a coffee. I also occasionally stream on Twitch.

🎹🎵 I made a new HTML & CSS only drawing 🎵🎹

Sarah — Sat, 22 Aug 2020 00:38:42 +0000

Photorealistic illustration of a Roland MC-500.

I wrote a few tutorials on how to create art like this:

Thoughts on Genderify, gender discrimination, transphobia, and (un)ethical AI.

Sarah — Wed, 29 Jul 2020 15:53:19 +0000

Earlier this week Genderify, an AI-driven platform that “identifies” users’ gender based on their name, launched and listed themselves on ProductHunt. They received a lot of very valid criticism both on ProductHunt and other social media, but I think they’re worthy of some more criticism from me on here as well.

Let’s start by taking a closer look at what Genderify really does. This is what they state on their ProductHunt page:

Genderify is an AI-based platform that instantly identifies the person’s gender by their name, username, or email. Our system can check an unlimited number of names, usernames, and emails to determine even the false ones and most incomprehensible combinations.

In practice, this means that you can enter any name, username or email address, and their platform will return two numbers: how confident they are that the person is male or female.

They make those predictions using data they obtained from publicly available governmental sources, and information from social networks.

They’re not clear how they obtained this information though, or which social networks they’re talking about, so it’s hard to go into detail about their training data, but they definitely did start with a biased dataset, even admitting so themselves on Twitter.

Most surveys, sign-up forms and government data don’t include genders outside of the binary. As I talked about in a previous article, the majority of forms only offer two options: male or female, entirely erasing non-binary people from their training data.

Then there’s also the issue that whether names are considered “male”, “female” or “neutral” is dependent on country, culture and language. It’s unclear how those are all represented in the datasets they used, but there’s a good chance that it’s heavily skewed towards the American perspective, if that’s where the majority of their data is collected.

So that biased, incorrect and incomplete dataset is what will decide which gender a user has based on their name or email address. What could possibly go wrong?

As of now, their AI only outputs numbers for two options, male and female. By doing so they not only erase, but also misgender, everyone outside of the gender binary.

A non-binary person will be given a male or female label based on their name. Even if they have a name that to most people in their culture is considered neutral, the system will still say they’re “most likely male” or “most likely female”.

This is very similar to giving people only two options to choose from on a form, which is already bad, with the difference being that an automated guess takes all choice away from the user and just assumes gender, making Genderify even worse.

Being misgendered is harmful enough already as it is, we don’t need tech companies to provide it as a service.

They are consistent though, as their predictions are wildly inaccurate for everyone, and don’t just affect trans and non-binary people. Some men got classified as women, Hillary Clinton was assumed to be a man, so was Oprah Winfrey, trash is considered male and male is considered female. I also tried to run the same name (Mathilde) once by itself, and once with a last name included (Mathilde Fossheim). Mathilde was labeled as a woman (85%), Mathilde Fossheim was labeled as a man (77%).

And as was pointed out by several Twitter users, they give very biased and sexists results for personality traits and professions as well. Adding a Dr. title to someone’s name instantly changes their assumed gender from female to male, nurse is labeled as female while doctor is labeled as male, wise is male and pretty is female, and the list goes on.

It’s not particularly clear what they expect people to use this API for, since in general it’s cheaper, easier and more accurate to just ask people their gender (or even better, to not collect any gender information at all).

Some are suggesting their service could mainly be “useful” for automating marketing and advertising, but there focusing on gender can again lead to reinforcing stereotypes.

But nothing is restricting their software from being used for other purposes. They praise themselves for having an easy to use API, starting from as low as $10 after the free trial expires. This means anyone can set it up and run an analysis on any dataset they have access to.

In those instances, being mislabeled by the system could for example mean being addressed with the wrong pronouns, losing access to information (think of the “women only” app that used facial recognition to determine whether you were allowed access), or facing discrimination based on assumed gender.

They now also provide the option to correct them if they mislabeled anyone, saying they’re “going to improve [their] gender detection algorithms for the LGBTQ+ community”.

This means that at some point they could even try to predict whether someone is more likely to be non-binary or trans based on their name. Given the harassment trans people already face (just earlier a Trump rally chanted to “Kill transgenders!”), providing free software to anyone that wants to try and identify them is outright dangerous.

Products like Genderify are harmful. They’re built on top of biased and inaccurate data, by people who seem to have no interest in risk management or the societal impact of their product, and released for basically no cost into the open for anyone to use.

I talked a lot about Genderify in this article, but the same criticism goes for a lot of other tech products. In 2017, researchers tried to build an AI that based on pictures predicts if someone’s gay, and just as recent as June 2020 a tool to depixelate faces was released. Then there’s also the examples of law enforcement using racist AI, racist AI being used for dynamic pricing and racist search engines, and the list goes on.

We really need to do better as an industry, and make ethics and risk management a larger priority. We can’t keep building unethical, discriminatory, racist, sexist, homophobic and transphobic products. If it’s not ethical, inclusive and accessible, it’s not innovation.

Navigating the internet as a non-binary designer

Sarah — Thu, 16 Jul 2020 13:25:20 +0000

This post was originally published on fossheim.io.

Earlier I wrote a twitter thread about small things designers can do to make their products more inclusive for trans and non-binary people. It’s a topic quite close to my heart, since I am non-binary myself, so I want to address some of the points in a proper post as well.

As I mentioned in the tweets, there’s more to trans/non-binary inclusive design than what will be discussed in this post, and there’s more to inclusive and ethical design practices than just gender issues. This will be an overview of things that can be done at relatively small cost, but will have a positive impact for gender diverse people.

But let’s first take a closer look at what it actually means to be non-binary. In short, non-binary is an umbrella term for genders that fall outside of the male/female gender binary. This includes several things, such as having no gender, multiple genders, a gender different than or between male and female, and culturally specific genders (such as two-spirit).

A lot of us use gender neutral pronouns (such as they/them), but it’s also common and perfectly valid for non-binary people to use binary pronouns (he or she), neopronouns, or a combination of different pronouns.

In my case, being non-binary means I am neither a man nor a woman, and exclusively use gender neutral pronouns (singular they/them).

I will include more resources explaining non-binary identities at the bottom of this post. For now, let’s get back to the topic of non-binary inclusive design.

Forms and data collection

Forms and surveys, both physical and digital ones, are notorious for excluding non-binary people.

Most often, they only have two gender options: male or female. Always presented as radio buttons or drop down menus, meaning only one gender can be chosen, and usually made obligatory, meaning a choice has to be made.

As a non-binary person, there’s no good outcome for me there. Either I lie and misgender myself as a woman, or I lie and misgender myself as a man.

Gender options on the Tinder iOS app. We want to find friendships or love that accept and respect our identities, but there’s no option for non-binary people to specify our gender. We have to list ourselves as a man or as a woman. Either way, we’re misrepresented from the start, opening the door for misgendering, harassment and abuse later on.

Fortunately, some forms do include a third option. Unfortunately, that third option is often “Rather not say”. I would very much like to say my gender, it’s just not possible.

Another option that’s often used is “Other”. While I assume that one exists because of the combination of good intentions (making sure people who fall outside the gender binary can answer) and technical limitations (both internationalization and limiting the amount of possible responses), it can easily come across as dehumanizing.

Society already emphasizes a lot that we’re different, falling outside the norms of binary cis women and men, so having to label ourselves as “other” online as well can feel rather damaging.

The three genders according to Facebook: Female, Male, Custom.

A similar situation over at Gmail. After choosing a “custom” gender, I had to choose whether my pronouns were male or female (gendering pronouns for someone who doesn’t gender themself feels wrong too; better would be to show an example), or other. There’s no information if “other” in this context means they/them, and there’s also no opportunity to actually write down my pronouns myself instead.

A better way would be to include a lot more gender options along with a “write in” or “not listed here” open text field. By calling the missing options “not listed”, the responsibility is also put on the designer/platform (they didn’t list us), rather than on the people filling in the form (we’re too “other”).

Another option is to just go for an open text field from the start, and make everyone write down their gender. Autocomplete suggestions can be used to discourage spelling mistakes, and with some post-processing of the data similar answers (eg “female”, “woman”, “women”, “womxn”) can be grouped as well.

Additionally, when offering different options, it’s also wise to consider going for checkboxes, rather than radio buttons or drop downs, allowing people to select several genders, rather than the one they most identify with.

But the way gender is asked for on forms doesn’t just exclude or harm non-binary folks, often the issues extend to binary trans people as well.

The following example comes from an article from 2016 about how to ask for gender in surveys, but is one I’ve come across in the wild on products as well.

By putting “female” and “transgender female” against each other, it’s implied that trans women aren’t real women (and same for trans men), or at the very least that they’re not “normal” women and men.

There’s not many instances where you’ll need to specifically know whether someone is a trans man or a cis man, for example. If you’re creating an interface for a doctor’s office, it might be useful for the doctor to know in order to call in their patients for the correct examinations.

Another example of where it could be useful to ask, is when collecting demographics data for research where the differences in answers between trans and cis people might be important (for example, a survey about online harassment).

In those cases, the example above could be adapted to:

Cis woman
Cis man
Trans woman
Trans man
...

Or alternatively, whether the respondent is cis or trans can be a follow-up question.

Do you even need to know gender?

The best way of avoiding most of these issues is by not asking for gender (or pronouns, or title) if you don’t actually need to known them for a specific and valid reason. For example Instagram uses they/them for everyone by default.

If you do need to ask, start by answering the following questions for yourself: why do you need to know this data, and how is it going to be used?

This will usually give you some more insights in what exactly you should ask the user, and which format the input should have. Gender and pronouns are not interchangeable - for example, as I mentioned earlier, not all non-binary people use they/them pronouns. Trans people their gender doesn’t match their gender assigned at birth. Gender and chromosomes/body parts aren’t interchangeable either.

Be specific, ask only what you need to know, and explain what the data will be used for.

Allowing for change

Gender, pronouns, titels and names might change over time, and it’s important to keep this in mind when designing and developing products.

When I changed my last name in 2019, I experienced first hand how difficult or even impossible it is to update my name in some systems. We use Jira at work, and despite having changed my name what feels like a million times in their settings, my old name I initially signed up with keeps being displayed.

And because it’s taking a while to receive an updated passport, there are still some services where I cannot sign up using my new legal name, but also cannot make or receive payments because my username doesn’t match my legal name, causing an administrative nightmare.

I also heard from trans people who, for a long time after changing their name in their account settings on Netflix, kept receiving promotional emails using their old name.

One form can cause a lot of harm

The examples above, and non-inclusive forms in general, can cause harm in several ways.

First of all, whether it’s non-binary people not having an option, or trans women not being classified as women, people end up being excluded and demonized. We’re either not represented at all, misrepresented, or invalidated.

In the Tinder example, where non-binary people might be shown as a wrong gender to potential new partners, the platform also puts all responsibility on its non-binary users to come out to their new matches, correct their pronouns and explain their identity. It’s tiring to constantly have to correct and educate those around us. Tinder had a good opportunity to take some of that burden away from us, but chose not to.

But in the age of big data, there’s more risks attached to misrepresentation in forms. The data we collect gets used and analyzed, and often fed into algorithms. Broken data leads to broken algorithms. And an entire group being erased from data collection leads to an entire group being erased from its analysis. Non-binary people are already invisible enough in society, forgotten about, underrepresented or not recognized as a real and valid identity. Our voices shouldn’t be erased even more.

A good example of this is a survey I had to take at some point in my career. The company I worked for at the time wanted to poll how we were doing, and what we thought about our work culture. The first question, obligatory to answer, was asking about our gender. There were only two options to choose from, male and female.

Further on we were asked if we thought the company was a safe place for queer people (sidenote, we were not asked about our sexuality either), and if we experienced discrimination based on our gender identity.

My answer, along with the answers of other non-binary employees, blended in together with those of men and women. Later on, both the external company conducting the survey and internal management patted themselves on the back: the company received a near top-score for gender equality, and almost no one reported feeling unwelcome because of their gender or sexuality.

Except with the majority of the company being cis and straight, and the answers of queer people not being represented correctly, an “almost perfect score” sounds a lot less perfect. How can they know that non-binary people experience harassment if they don’t even give us a proper voice?

Language matters

Being a non-binary person in tech, I often am wrongly put on “women in tech to follow” lists. While it’s a nice sentiment, who doesn’t like some validation for their work, it puts us in an uncomfortable position. First of all, because I’m not a woman. It’s misgendering me. But pointing that out, no matter how politely, also opens the door to a lot of (verbal) abuse.

And similarly, a lot of events and communities try to show they’re inclusive by saying they’re open for “women and non-binary people”.

For non-binary people like me, it feels bad to always be grouped together with women, especially because I often get misgendered as one. So to me, it’s never clear whether people will actually welcome me for who I am, a non-binary person who’s neither a man nor a woman, and respect my identity, or if they will look at me as a woman or a “woman-lite”.

And for some non-binary women the division between “women” and “non-binary people” can be experienced as harmful as well.

So while the intention behind “women and non-binary people” might*** be good, the language can actually end up excluding more people than includes, and create unsafe and unwelcoming spaces.

*sometimes it’s also just a meaningless phrase to seem more inclusive without having to put in the work.

The same goes for language used when advertising products. “Menstrual products” is more inclusive than “feminine hygiene”, similar to how “people who menstruate” in context is more inclusive than “women”; because not all women menstruate and not all those who menstruate are women.

Representation, harassment, discrimination and a lot more.

In this post I only highlighted a few challenges and and possible solutions. Non-binary and trans people are still underrepresented, both in the design and tech industry, in our research, and in the content published on our platforms. We‘re underpaid, discriminated against and face harassment. Just the other day I had to block someone on Twitter for harassing me and a non-binary friend of mine about our identity.

There’s a lot more to dive into in follow-up posts, but until then I suggest checking out the following resources:

#InternationalNonbinaryDay and #NonbinaryAwarenessWeek

I’d also like to end this post on a positive note. While navigating the internet as a non-binary person brings up uncomfortable, painful and sometimes abusive situations, the internet has been a massive help for me as well to help me come to terms with my gender identity.

There’s a lot of information out there, hashtags that are meant to raise awareness and uplift non-binary voices, and even an entire community of queer designers and transgender and gender diverse people in tech.

And as I’m writing this post, it’s International Non-Binary People’s Day, as a part of Non-Binary Awareness Week. It’s great to see effort being put into raising awareness and visibility, and I’m really damn proud to be non-binary.

If you found this post useful, consider sharing it on social media, or subscribing to my Patreon for early access to future posts.

Forem: Sarah

Dataviz accessibility review: what we can learn from the Norwegian 2023 election graphs

Scope

Data visualizations require accessibility work

Graphical elements that carry meaning need text alternatives

We may need to provide additional context and structure to the data to make it screen reader accessible

Similar charts can have different valid solutions

Not testing visually hidden labels can lead to incomprehensible data

Graphical elements require 3:1 contrast with the background

The page itself needs to be accessible too

Heading levels are important for explaining the structure and relationships of the content

Internationalization needs to be considered

Maps are tricky to get right, often ignored

The election maps were lacking screen reader interaction, table alternatives, and informative text alternatives

Public vs. private sector?

Looking for an accessibility review, training, or help with dataviz accessibility?

Looking back at the past year (and a half) of accessibility work.

Work

Accessibility Observations

1. Many people actually do want to prioritize accessibility.

2. The tech industry faces a lot of accessibility blockers.

3. Accessibility bugs are more often caused by broken processes than broken code.

4. Progress over perfection: small improvements can go a long way.

Looking into 2023.

Building an accessible theme picker with HTML, CSS and JavaScript.

What we’ll be building

Variable styling with CSS.

Creating a theme selector component in HTML.

Communicating the selected theme.

Updating the selected theme with JavaScript.

Reacting to button clicks.

Adding theming info to the buttons.

Updating the theme.

Updating the button properties.

Saving the choice.

Updating the local storage.

Code cleanup

Final result

Resources

I drew a synthesizer with HTML & CSS

How to create a screen reader accessible graph like Apple's with D3.js

Before we start

Part 1: Drawing the rings.

Alternative: Using aria-label

Part 3: Explaining the data.

Alternative: Expanding the aria-label solution

Next steps.

Bonus solutions:

Different type of input.

Navigate through the activity rings.

Excluding non-binary people by design: How sign-up forms can lead to discrimination

How Google allowed this discrimination to happen.

Alienated and erased by design.

Lack of data, visibility and accountability.

Preventable accidents.

What we can learn from Apple's dataviz accessibility

Daily activity breakdown

Activity rings

ECG

Blood oxygen

Watch faces

Highlight cards

Apple’s graphs set a good example, so what can we learn from them to make our own visualizations more screen reader accessible?

More resources to get you started

I launched a directory with ethical design resources

How (not) to make accessible data visualizations, illustrated by the US presidential election.

Screen reader support

Read all the data

Link to an accessible data table

Give data a human voice by using titles and descriptions

Keyboard navigation

Accessible colors

Brightness

Make data easy to find and understand

How to continue from here

🎹🎵 I made a new HTML & CSS only drawing 🎵🎹

Thoughts on Genderify, gender discrimination, transphobia, and (un)ethical AI.

Navigating the internet as a non-binary designer

Forms and data collection

Do you even need to know gender?