Accessibility Checkers

by Kristin Briney Posted on 2026-10-05

I’ve been on a quest to help make research data more accessible by educating everyone about the steps that they can take to improve file accessibility. For someone who hasn’t done this work before, making accessible files can feel overwhelming. But today, I’m going to share a type of tool that will help make accessibility a little bit more achievable: the accessibility checker.

An accessibility checker is a tool that uses a set of established criteria to identify inaccessible content and point out how you can improve the accessibility of that content. Checkers can be built into software, available as a downloadable tool, usable as a browser plug-in, executable on the command line, and more. Checkers are also available for a wide range of content types and accessibility issues.

Let’s look at some examples of accessibility checkers. Common software that has a built-in an accessibility checker includes: Microsoft Word, Microsoft Powerpoint, Microsoft Excel, and Adobe Acrobat (the paid version). Other accessibility checkers are external tools, such as WebAIM’s Contrast Checker which looks for sufficient color contrast between tested colors. While Contrast Checker works for many types of files, other checkers work on one specific type of content. For example, the WAVE tool and Silktide both assess the accessibility of webpages. I’ve used all of these tools but if you need a different checker, I encourage you to check out the Web Accessibility Initiative’s list of over 100 accessibility checkers.

Accessibility checkers are really useful, particularly for those new to accessibility who are looking for a place to start, but they aren’t universal or foolproof. For example, I recently used Adobe Acrobat’s built-in accessibility checker to improve a workshop handout. While the checker found several issues for me to fix, it didn’t automatically test color contrast, which I had to test by hand. Checkers may also be insufficient for testing complex or interactive content. Despite this, I found these tools to be useful for giving me a starting point for improving accessibility by pointing out the most glaring issues.

If you’ve never thought about accessibility and want to make your content more accessible, I encourage you to try out an accessibility checker. It will do the work for you to identify content that’s not accessible, allowing you to focus on specific improvements. Checkers are not perfect, but they are a great tool for taking measured steps toward greater accessibility.

Posted in accessibility | Leave a comment

File Naming for File Sharing

by Kristin Briney Posted on 2026-09-02

I am a huge fan of strong file naming, specifically using file naming conventions. Such conventions provide consistent and descriptive names for a group of files. A good file naming convention can add order to your files while you are actively working on a project and make files easier to find later. Given the choice, I will always teach file naming conventions and their partner, the date format ISO 8601, when teaching data management basics.

There is one caveat to file naming conventions that I have not yet discussed: how to name data files that you share. I’m not talking about collaborative data sharing, where you and your colleagues are actively sharing lots of files back and forth during a research project — this scenario hugely benefits from using a naming convention. Rather, how do you name data when you are only sharing a small handful of files, such as for public data sharing? When sharing only a few files, sticking with your detailed file naming convention doesn’t make sense because it is probably difficult to interpret.

When sharing a small group of files, you should name your files for clarity. So instead of naming your file “AWA_MK01_20180222_Notes.pdf”, a better name is “InterviewTranscript.pdf”. (Based on those two names, which one gives you a better idea of what the file contains?) If you are sharing one data file with an article, you could also name your file after your article, as in, “abbreviatedArticleTitle_data”. There aren’t strict guidelines for this type of naming beyond making sure you pick a simple name that accurate reflects what is in the file.

Focusing on clarity when naming a small group of shared files is superior to using a detailed naming convention because using clear names makes it easier for someone else to quickly understand what is in those files. A lot of the problems that naming conventions solve go away when you have less than ten files. For example, differentiating similar files is much less of a problem if you only have a few files. It’s also likely that you are sharing your best data, meaning you don’t necessarily need to record a bunch of experimental parameters in the file name.

File name clarity is actually an accessibility issue as clear file names are easier for disabled people, such as those with cognitive disabilities and people who use screen readers, to understand. Actually, clear file naming helps everyone easily understand what a file contains, disabled or not! This is another case where universal design benefits everyone.

Note that the same rules about characters in file names apply no matter how you choose to name your files:

  • Stick to alphabetic and numeric characters;
  • Don’t use special characters like: &, $, %, #, @, etc.;
  • Don’t use spaces in file names (not every operating system can handle spaces in file names);
  • You can separate words in a file name with an underscore “_” or dash “-“;
  • Instead of using a separator, you can alternatively use “PascalCase” or “camelCase” by capitalizing the first letter in each word (it’s your choice how to handle the first word in the name);
  • Keep your file names short, ideally 25 characters or fewer.

Next time you have to share a few files, such as in support of a published article, I hope you ditch the file naming convention and opt for clarity in your data file names. You will still want to describe those files in a README.txt file, but anyone who looks at your data will appreciate the clearer names.

Posted in accessibility, dataManagement, openData | Leave a comment

A Surfeit of Data Management Books for Librarians

by Kristin Briney Posted on 2026-08-04

I’m really partial to books about data management. This might be because I am currently writing my fourth book relating to data management, but there are honestly lots of great data management books out there. There are actually so many books available that it can be hard to identify the best book to fit your needs.

Last year, my friend and collaborator Abigail Goben and I took on this issue by publishing an annotated bibliography of data management books for researchers. That article describes the 17 books that cover data management topics across a range of research disciplines.

Now, Abigail and I are back with an annotated bibliography of data management books for the librarian audience. There are 32 English-language books on this list, including several books that discuss library data services broadly. (Aside: I find it a bit frustrating that there are almost twice as many books for librarians than for researchers on this topic, but I guess that means less competition for my books, which are aimed at researchers.)

Our goal for the article was to provide information about what each book covers and which books we recommend in different areas. Given that there are so many books and the fact that most cost between $50 to $100, I don’t expect any of my peers to purchase all of them. So we’ve done an initial pass to help guide you. In particular, Abigail and I had a lot of fun writing the summaries of each book and then editing each other’s words.

A couple interesting things came out of the analysis of this pile of books. The first is that we (librarians) are publishing a lot of edited collections, which represent 20 of the 32 books (63%). I tend to find books written by a single or a few authors to be more useful than a book with different authors for every chapter – the exception is books on narrow topics, such as teaching data management, where multiple perspectives can be valuable. As we have so many books on data management/data services, I personally think that these broad edited collections have diminishing value to me as a reader (even though I admit to having written chapters in a couple of them).

The other interesting thing in our article is a topical analysis of all of the books (see Table 3 in the article). Certain topics were (unsurprisingly) covered frequently – data education, data management, data repositories, and curation – but I find the less frequently covered topics to be more interesting: data accessibility, high performance computing, community data (including Indigenous data and the CARE Principles), and creating a data catalog. Acquisition editors in particular should pay attention to this table and guide potential book authors to fill the gaps we have in the literature rather than publish yet another introduction-to-library-data-management book.

If you are a library worker doing data work, I hope you find this annotated bibliography to be useful. The article is open access (with a Creative Commons Attribution Non-Commercial license), so feel free to use and reuse the information!

Posted in bookReview, dataManagement, libraries, publishing | Leave a comment

Research Data Accessibility Report

by Kristin Briney Posted on 2026-07-16

I’m very excited that the RDAP report “Accessibility for Data and Data Repositories: Understanding and Applying the 2024 ADA Title II Rule” is now available. I was a co-chair of the group that wrote this report, alongside Rachel Woodbrook and Clara Llebot Lorente, and we worked with a fabulous group of peers to write this 100+ page document.

The report is useful for librarians and researchers, as well as anyone else interested in making research data more accessible. While the title frames the report with respect to U.S. disability law, the guidance within the report are broadly applicable to other countries.

Researchers interested in data accessibility should skip to section 4, which is about the accessibility of research data. That section contains a lot of guidance on making data files accessible, from spreadsheets to images to video and textual data. This section provides general guidance by data type and then specific guidance for select file formats within that data type, complete with screenshots on how to implement the guidance. The hope is that by making data accessibility guidance available and easy to follow, researchers can start making their files for accessible.

This report has been a labor of love in an area (data accessibility) where little guidance can be found. I hope that many people find this report helpful. It’s also CC BY licensed, so you are free to reuse this information and share it widely!

Posted in accessibility, dataManagement | Leave a comment

Plain Language for Research Data Documentation

by Kristin Briney Posted on 2026-07-06

Today, I want to continue to discuss various ways to make research data more accessible. While there are specific accessibility recommendations for specific types of data files, such as recommendations for accessible and reusable spreadsheets, we’re going to focus on something more general today: plain language.

Plain language is a clear way of writing that makes your content easier to understand. Plain language doesn’t necessarily apply to research data (as you shouldn’t alter data), but is a good strategy for documentation, where you have direct control over what you write. The idea is that if you write your documentation more clearly, people will better understand your data and can more easily reuse it. Using plain language is also an accessibility issue, as it helps people with various cognitive disabilities better understand written content.

So what does plain language look like? Plain language recommends simplification wherever possible. Some common recommendations for plain language include:

  • Write the most important information first;
  • Keep sentences short and direct;
  • Keep paragraphs short;
  • Break content into sections and use headings;
  • Avoid jargon;
  • Define acronyms and abbreviations;
  • Use bullet pointed lists, where possible.

You can adjust your writing to your audience and use research-specific terms, but remember that some researchers in your field may not be native English speakers. So plain language for research documentation should balance using clear and direct words against field-specific terminology.

Plain language also involves writing at a lower reading level, typically no higher than a lower secondary education level (WCAG 2.2, Criterion 3.1.5). Even with the ability to adjust your writing to your audience, assuming a lower reading level will make your writing more accessible to everyone, even those without disabilities.

Let’s look at an example of plain language. Let’s start with the sentence: “based on the state of the local flora and where we are in the growing season, I recommend ceasing the collection of samples.” A plain language version of that sentence is: “do not pick the flowers.” The second sentence is much clearer and more direct and means roughly the same thing.

Writing in plain language is an art and takes practice. But I encourage you to think about plain language the next time you create research documentation so as to make your documentation (and thus your research data) as accessible as possible.

Posted in accessibility, documentation | 1 Comment

Color Accessibility for Research Data

by Kristin Briney Posted on 2026-06-01

Last month, I blogged about the need to include accessibility in the discussions of research data reproducibility and reusability. This month, I want to address one way to do that. Specifically, we’re going to talk about color.

Color appears in research data in a number of places, most obviously in image and video files, though it can also appear in text and spreadsheets. Where we currently see accessibility guidance around color, such as when journals provide guidance for figures, it is frequently guidance to avoid red-green pairings because of color vision deficiency (colorblindness). But actually, accessibility guidance around color goes beyond this.

The first accessibility recommendation for color is to never use color as the only means of conveying information (WCAG 2.2, Criterion 1.4.1). One of my standard examples of this is to avoid highlighting cells in Microsoft Excel to encode information that is not available in another form. Not only can a blind person not access this information (because there is no textual equivalent that can be read by a screen reader) but also, a computer cannot perform calculations upon highlighting. Any information that is only shown as highlighting should be converted to a separate text-based variable on the spreadsheet. For images and video, the scenario is a little different. For example, if you are taking a photograph, you cannot change colors in the image without changing the underlying information in the image. Instead, you should provide a text alternative (called “alt text“) that describes what is in the image. In general, for any information encoded as color, it’s best to also provide that information in another form – typical, but not always, a text equivalent – that can be read by a blind person using a screen reader or a computer.

The second recommendation for accessible color is to chose colors with enough contrast. Obviously, you cannot change colors in a photograph without altering the underlying data (this is another reason why alt text is important) but you can chose colors in a data visualization and for other types of data. Choosing colors with high contrast means that your visualization will be understandable by a person with low vision as well as for someone who prints everything in black and white. The recommended contrast ratio for adjacent color blocks is 3:1 (WCAG 2.2, Criterion 1.4.11). WebAIM’s Contrast Checker tool is useful for checking your contrast ratios. There are also tools, such as Coblis, for checking colors against the various forms of color vision deficiency (because red-green isn’t the only type). I recommend that you make it part of your workflow to always check your color schemes for contrast before finalizing them.

The 3:1 contrast ration is specific to blocks of color. Guidance is a little different for color of text. The contrast ratio for text is a minimum of 4.5:1 (WCAG 2.2, Criterion 1.4.3), though a ratio of 7:1 is even better (WCAG 2.2, Criterion 1.4.6). When in doubt, black-on-white is best. There are other accessibility recommendations for text that cover issues beyond color, such as typography and font size, and I encourage you to check out guidance from Section 508 and WebAIM on this topic.

Overall, there is a lot of leeway in color choice when it comes to accessibility, so long as: 1) color-based information is also encoded in some other way; and 2) you use enough contrast in your color choices. WCAG 2.2 guidelines (which are the go-to web accessibility guidelines I’ve been referencing throughout this post) don’t actually say anything about color choices for color vision deficiency. Accounting for the various forms of this disability is nice to do when you are able to do so, but a lot of the concern in this area is reduced by having enough color contrast.

Hopefully this guidance will be useful to you. You don’t need to remove color from your data and you can still choose fun color schemes. You just need to add a few checks to your workflows around color to make sure your data is maximally accessible.

Posted in accessibility, digitalFiles | Leave a comment