Making Open Data Platforms More Accessible

Published in

CivicDataLab

7 min readNov 10, 2021

Modern web platforms are aiming to reach the next half billion population, working to onboard first-time internet users to have a seamless digital experience. You would often hear terms like Accessibility, Inclusivity, screen-reader friendly, and so on. As developers, we shouldn’t be afraid of these words, but at the same time build our capacity to do justice to them.

In this blog, which is hopefully the start of a series, I talk about how I, as someone fairly new to the term web accessibility, how I learned about it, implemented it, and hopefully can encourage you and other developers in the community to adopt it in their development process as well.

First, let’s understand the title:

Open Data Platforms are platforms that proactively publish Open Data — data that can be freely used, re-used, and redistributed by anyone, subject only, at most, to the requirement to attribute and share-alike. We at CivicDataLab, co-create several Open Data Platforms where we enable citizens to search, access, analyze, visualize and download crucial data without any restrictions. We have built platforms like Open Budgets India, Justice Hub, Zombie Tracker, and more such open data platforms are in our pipeline.
Accessible here stands for web accessibility, which means building an inclusive web. What we mean by “inclusive web”, is that products are designed and developed in a way that people irrespective of their disabilities can use them.

Schemes Dashboard

The open data platform that I will be talking about in this blog is the Schemes Dashboard. It’s a platform where we can find information related to several schemes run by the Indian Union and State governments. The dashboard is developed by CivicDataLab in collaboration with CBGA. It’s an open-source project with MIT License and is available on GitHub.

Making Schemes Dashboard Accessible

This particular platform is built from multiple interconnected components to make it easier for users to navigate and make sense of the data presented. I will go through these components and the steps I took to make them more accessible.

Focus Indicators

Let’s start with something global. Focus Indicator is the cursor equivalent for keyboard users and we will improve the one that comes pre-built with the browsers. You can read about it in this blog post by Sara Soueidan

But firstly, never do this:

:focus {
 outline: none;
}

Why? Because doing this is blinding the users who use the keyboard to navigate through the web. Imagine yourself using a mouse but not being able to see the cursor on the screen. That’s what it feels like.

I’m guilty of doing this in my early projects as well but it’s the mistake that we all learn from.

It can be easily fixed with something like this:

:focus-visible { 
 outline-width: 3px; 
 outline-color: #78aeda; 
 outline-style: solid; 
}

outline-color can depend on your platform’s theme.

2 links, left one is without an outline on focus and right one is which a outline of blue color — A link without and with a focus indicator

Adding a better focus indicator will let the users who cannot use the mouse know their current position on the site.

Skip Links

Another global feature, skip-links help keyboard users to skip the repeated components like links in the navigation menu and other elements and jump to the main content.

There is an excellent guide on how to create a skip-link on CSS-Tricks. It’s also the one that I used to implement this feature on Schemes Dashboard.

skip link which is hidden by default but is made visible on focus — Skip link can be hidden and shown only on focus

Problem with Skip-links on Next.js

We can use Next/Link to add transitions between pages but, it creates an issue where when the new page is loaded, it does not focus on the skip-link on the first Tab, instead, it bypasses it.

To counter this issue, we can add a new element before the skip-link and initiate a focus on it whenever there is a route change.

<span id=”top-of-site-pixel-anchor” tabIndex=”-1"> 
 &nbsp; 
 </span> 
 <a className=”skip-to-content-link” href=”#maincontent”> 
 Skip to content
</a>

and on the _app.js file:

React.useEffect(() => {
 const handleRouteChange = (url) => { 
 // change focus to top 
 document.querySelector(‘#top-of-site-pixel-anchor’).focus(); 
}; 
 Router.events.on(‘routeChangeComplete’, handleRouteChange); 
 return () => { 
 Router.events.off(‘routeChangeComplete’, handleRouteChange); 
 }; 
});

Cards

One of the requirements for the homepage was to add a card layout that makes it easier to click and select the desired scheme and access it. Some points I considered here:

Adding a link to the card instead of adding a ‘read more’ inside the card turned out to be a better option. It gives a big surface area for mobile users to click on.
If there is an illustrative image inside the card, use a blank alt tag, i,e, alt=” ” so that the screen reader does not announce the images.

You can read more on how to create inclusive cards in this post by Heydon.

External Links

The platform has external links and, we must announce it as so for the screen-readers. We can do that by adding something like:

<span class=”screen-reader-text”> :opens in new window</span>

and it’s a good time to introduce this helpful class:

.screen-reader-text {
 border: 0;
 clip: rect(1px,1px,1px,1px);
 clip-path: inset(50%);
 height: 1px;
 margin: -1px;
 overflow: hidden;
 padding: 0;
 position: absolute;
 width: 1px;
 word-wrap: normal !important;
 color: #222;
 background-color: #ddd;
}

We can use it to hide content visually but announce them to screen readers. For users that rely on screens and not readers, we can add an SVG icon to let them know or use something like this as proposed by w3.

Toggle between Visualizations

Schemes Dashboard’s main purpose is to present data visualizations and there are multiple types of visualizations, including Choropleth, Bar Graph, and also a table. The act of toggling between them should be accessible as well.

A couple of points of consideration:

Use <fieldset>, <legend> and <labels> tags appropriately.
Another way to build it is by using <ul> and <li> with roles of ‘presentation’, ‘tab’ and ‘tablist’.
You can use ‘screen-reader-text’, in case you need to hide something visually.

You can read more about accessible toggle buttons in this post by Heydon and another post by Sara.

Data Tables

Usually, it’s advised to not use <table> unless required. Schemes Dashboard was one of those cases where it was required to use data tables. So if we are going to use it, we better make it inclusive.

The dashboard includes a basic table that can be improved by implementing sort functionality. Just make sure to:

Not put everything in the <tbody> tag
Use <thead> for the heading.
Use <caption> tag appropriately.

You can read more about Inclusive Data Tables.

More Considerations

Here are some more points that we can consider while building the platform:

Involve people with disabilities in user research.
Implement inclusivity in the design process.
Check the components using screen-readers, NVDA is available for free.
Don’t disable buttons. Read more about issues with disabled buttons.
Use alt tags.
Use extensions like Wave by WebAim to evaluate web accessibility within your browser.

Accessibility is important

There might be various reasons why someone is looking to make their platform more accessible than it already is.

You care about your users, so you want all of them to use your product.
It’s in the signed agreement, so it’s one of the deliverables.
You might do it because the platform which is accessible provides a better experience to people without any disabilities if compared with the non-accessible platform.

There are more reasons, and I would like to add one. “As a developer, it’s our job to fix what we broke.” The Web, by itself, is perfectly accessible. It’s when we add those fancy carousels (which don’t work by the way) is when we break it.

Also, when we make a platform inclusive, it enhances the experience of everyone, not just folks with disabilities.

Accessibility is NOT hard to implement

WebAIM Million is an annual accessibility analysis of the top 1 million home pages. As per the results, year after year, it turns out that most of the WCAG 2 problems are something that can be fixed with just a little caution during the design and development of the platform.

Top Accessibility Issues on tested 1 Million in 2021

Here is a trend of accessibility issues for last 3 years:

96.7% of all errors detected during the testing fall under these 6 categories. So if we just fix these, we are already improving the web by a wide margin.

Closing Thoughts

At the end of the day, we have to be aware of the fact that whatever we are building is for our users. Users should be included from the start of the design process if we aim to build an actual inclusive product.

For Open Data platforms, we can’t call them open if we are excluding users from accessing the platform at all. So while keeping all of that in mind, I believe we can make platforms accessible, inclusive, and screen-reader friendly.

Disclaimer

Scheme Dashboard, which I talked about in this post is the second platform to be made accessible after Budget Basics. Our aim is, as we study more about accessibility, integrate it in our build process, we will improve our future platforms and also the ones that are already built.