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

Disability and Data Sharing

by Kristin Briney Posted on 2026-05-04

I’ve been blogging a little bit about topics at the intersection of accessibility and data sharing in the last year or so. This has been due to my having Long COVID and reinterpreting how I think about my body and my research. As I learn more about disability, I’ve made more and more connections between disability and data sharing. In today’s blog post, I want to examine this overlap in more detail to convince others that that the accessibility of research data is an important area to address.

According to the U.S. CDC, 28.7% of all Americans have one or more disabilities. Disability numbers out of the UK are about the same: 24%. Disability is actually very common. It’s a group that everyone is likely to be a part of at some point, especially as we age.

Due to the role of disability in society, disabled people are under-represented as researchers. Only 22.2% of people with disabilities hold a bachelor’s degree or higher (as compared to 42.6% of people without disabilities). It gets worse the further you go in academia. The 2023 U.S. National Science Foundation’s (NSF) Survey of Doctorate Recipients found that between 10-15% of U.S. doctorate recipients were disabled, with numbers varying across fields. All of this leads us to conclude that, while disability may be under-represented among researchers (who are more likely to hold higher degrees), it is still very present.

You may already work with a researcher who is disabled. With the high prevalence of non-apparent disabilities (disabilities that are not obvious by looking at someone), it’s likely that you know a disabled researcher even if you don’t know that they are disabled (waves hello). The point is that disability is common in research even if we aren’t always aware of it or talk about it.

How does this relate to research data? For all we speak about data being reproducible and reusable, I argue that data can not truly be reproducible and reusable unless it is usable by disabled people. If we speak about data being usable by those outside of our labs and how to format data to maximize this, disability needs to be a part of the conversation. Several people have made the point about the need for accessible research data before me, the most recent of which is Colón, Goben, and Karcher who argue for “actually accessible data”. I encourage you to check out their paper, which includes a call to action in this area.

The challenge of making data more accessible to disable people comes down to the details. There are known strategies for making business files more accessible, which can be translated into the research context, but this is far from covering the complete spectrum of research data. Additionally, some of the recommended accessibility strategies (such as formatting requirements for Microsoft Excel files) are in conflict with current reproducibility recommendations (such as to use CSV files with no formatting). At this point in time, there is only a small amount of guidance specifically about making research data files more accessible.

I don’t have an answer to the challenge of making research data files more accessible, though I am slowly trying to chip away at pieces of the challenge. I hope other people will join me in this exercise. I plan to blog more here in the future about any progress I make in this area.

Posted in accessibility | 1 Comment