Accessibility

Introduction

Digital accessibility ensures that people can perceive, understand, navigate, and interact with websites and digital tools regardless of auditory, cognitive, neurological, physical, speaking, or visual abilities. Accounting for accessibility removes barriers for people with disabilities and can make web interfaces and information more enjoyable for everyone. Making information accessible helps broaden access to scientific research, and reflects the American Chemical Society’s core values.  

This section introduces best practices for making accessible digital and (some) print content. It is not exhaustive but serves as a starting point for deeper research or conversations with developers. It also does not prescribe legal or institutional policy but is intended to provide evidence-informed options for accessible communication. Our recommendations draw on guidelines from multiple organizations, institutions, and advocacy groups, with examples primarily from ACS publications. Examples with the phrases “Use/Avoid” indicate practices explicitly mentioned from the Web Content Accessibility Guidelines (WCAG). Examples with the phrases “Consider/Instead of” offer one of several options, acknowledging that different approaches may be taken. This section ends with references to additional resources that can provide more detailed guidance and recommendations.

Users should consult their organization’s policy when preparing materials for official contexts. In some cases, taking steps to make information accessible might be necessary to comply with the Americans with Disabilities Act (ADA) or other relevant regulations. 

Some inclusive options may require specialized expertise; if that’s the case, assess whether the project requires consulting accessibility professionals and/or engaging with end users with disabilities. This section is organized by project phase (project planning, project execution, and finishing touches), highlighting the most relevant considerations for each phase. Some recommendations can also improve the usability of print products (such as PDFs).

For more information, see the Web Content Accessibility Guidelines, recognized globally as the standard for web accessibility, and more resources listed in “Resources on accessibility.” 

New Work

Background:

Designing content with accessibility at the start is easier and more cost-effective than retrofitting existing media. For example, it’s easier to incorporate markup languages or Accessible Rich Internet Applications (ARIA) labels during website development than to add them later. Similarly, writing a video script with integrated descriptions is easier than adding descriptions after recording. See also “Markup languages and ARIA attributes” and “Videos.”

Inclusive options:

• Start your project design process with accessibility in mind.
• When possible, involve coders and designers who have experience with accessibility, or who have a disability themselves. They are often best equipped to apply accessibility guidelines effectively. 

Assistive devices and technologies

Background:

Many devices and technologies help people with disabilities access information. The type of device or technology used depends on the disability and kinds of media they are interacting with.

Examples include: 

• Screen readers: Common tool for people who are blind and low-vision (but also people without vision-related disabilities). Screen readers read text from computer programs, messages, web pages, emails, e-books, and more aloud or sends information to a braille display. 
• Braille display: Devices that use tiny pins to form braille characters that can change as the user reads or as the text updates. Some devices print braille on paper for offline reading.
• Speech-to-text software: Renders spoken words to text.
• Voice control software: Allows users to vocally issue commands to a device. 
• Eye-control or laser pointer systems: Assists people who cannot use a keyboard or mouse. 
• Screen magnifiers: Helps people with limited vision to enlarge content. 
• Adaptive keyboards: Includes extra large keys or ergonomic designs for one-handed use.

Inclusive options:

• Be aware of assistive technologies. When developing content, keep in mind the various ways that people will navigate digital and print information.
• Consider testing for accessibility. Navigate with different kinds of assistive technologies, if possible. A simple method is to test navigating a web page or platform with the tab key, or using a screen reader built into your operating system.
• When possible, ensure that people with disabilities or people experienced with using the technologies can help with testing.
• See also, “Keyboard navigability.”

Writing for accessibility

Background:

Clear writing can help everyone understand information more easily. Plain language is a method of writing that uses clear and simple wording. It can make text more accessible to people with cognitive conditions and people who speak English as an additional language. 

Plain language typically:

• uses simple sentence structures,

• favors active voice (where the subject performs the action),

• puts the most important information first,

• defines difficult but important terms,

• defines abbreviations before using them,

• avoids idioms and jargon,

• uses familiar words, and

• uses bullet points instead of long in-line lists. 

Plain language isn’t always the best option. Fiction or creative writing rarely work well in plain language, but informational material or content intended for broad audiences can. When content is translated into plain language, it’s common to provide both plain and standard versions. Whichever format chosen, ensure the tone is considerate of the reader. 

Incorporating plain language principles into scholarly and technical writing, particularly abstracts, can make science and science findings more accessible to a broader audience. Providing plain language summaries to scholarly articles has become increasingly common. Many journals and funding sources have started to require plain language summaries to raise awareness of scientific topics or medical issues.

Inclusive options:

• Use plain language when the information is particularly relevant for readers with cognitive disabilities or readers who could benefit from simple presentation. 
• Consider adopting principles of plain language for technical writing and scholarly scientific work to make findings more accessible. 
• Write in clear, direct sentences that place the most important information first.
  • Use short sentences and familiar words.
  • Use active voice, where the subject of the sentence performs the action.    

Example:

Fonts and typefaces

Background:

Ornate or hard-to-read typefaces can make text difficult for people with dyslexia and other cognitive disabilities. Common and widely available typefaces, including Arial and Helvetica, help avoid accessibility barriers in digital and print contexts. A font refers to the styling of a typeface, including their size and whether they are italicized or bold. A typeface is a specific design of type and can use serifs (a small line or stroke added at the ends of letters). Sans (meaning without) serif typefaces omit those strokes. Both font choice and whether the typeface is serif or sans serif can affect readability. Using too many different fonts or typefaces in the same document or site can reduce readability. 

Accessibility experts disagree on whether it’s important to avoid serif fonts entirely. In general, sans serif typefaces, such as Helvetica, can be clearer when ornamentation is distracting, however, some people have difficulty differentiating sans serif characters such as “p,” “q,” lowercase “L” and uppercase “i,” or “b,” and “d.” In general, choosing a common typeface in large font, depending on context, is most accessible.

Inclusive options:

• Use readable, common typefaces and ensure spacing between letters and words are adequate but not overexaggerated.
• Avoid heavy stylization, such as all caps, shadows, or text layered on other text.
• Avoid large sections of italicized text. 
• Use consistent font and typeface throughout one document. Avoid mixing too many styles.
• Use at least 12-point font size or larger for normal text in email or documents.
  • Slide presentations: Use at least 24-point or larger for body text and 28 - 38-point for titles.
  • Posterpresentation: Use 24 - 30-point for body text, 36-60-point for headings and subheadings, and 45 - 120-point font for title, depending on length.

Hyperlinks

Background:

Some users experience link text separately from its surrounding content. This means phrases such as “click here” are unhelpful because the purpose of the link is missing. Link text should describe the link's purpose or destination so readers understand the purpose without additional context. Avoid very long link text presented as full URLs because they can be cumbersome for screen readers. Extremely short links (such as a single character) may be difficult for some users to select. Aim for concise, descriptive link text that balances clarity and usability.

Inclusive options:

• Use descriptive link text that clearly tells readers where the link will lead. Don't use ambiguous language, such as “click here” or “read more.” 
• Avoid linking entire sentences or long phrases.
• Avoid very small links or elements, such as a single text character. 
• Long URLs are best presented as linked words instead of displaying the full URL. Short or vanity URLs are generally ok.
• If link text cannot adequately describe the link location, add hidden descriptions for screen readers such as markup or ARIA attributes. See “Markup languages and Accessible Rich Internet Applications (ARIA) attributes.” Even generic link text can provide meaningful context for assistive technology. For more information, see Web Accessibility in Mind’s tips on links and hypertext.

Example:

Alternative text and image descriptions

Background:

Alternative text (alt text) is embedded in digital visuals. It appears when an image fails to load. Screen readers also use alt text, making it essential for people with low or no vision to interpret any non-text elements, including photos, tables, graphs, and graphics. Alt text should describe what the image shows without repeating the caption, as a screen reader reads both. 

For simple images, most guides recommend keeping alt text concise (100 – 150 characters). Overly long alt text can burden users. There is no strict limit, but longer descriptions for more complex images, such as charts, graphs, or infographics (see “Infographics”) can be added using different methods.  

Alt text isn’t usually visible, but image descriptions often are. They are positioned next to or beneath a caption in addition to the alt text and used most widely on social media. Image descriptions are longer and can encompass more context and tone. If an image description doesn’t fit with the caption, it’s also acceptable to add it in the comment section of a social media post.

There’s ongoing debate on how specific alt text should be in describing characteristics such as race or gender of people portrayed in an image. Some advocates argue that it’s best to include race, for example, to counter a false, socially-constructed narrative that the default subject is White. Others caution that describing such characteristics risk misidentification of the person or people portrayed in the image. 

Inclusive options:

• Provide clear, concise alternative text for images and other non-text features wherever they appear online, including on social media. 
• When writing alt text for images of people, include characteristics that help readers understand the image's meaning. Make an informed choice about whether to include other details. 
• For longer alt text, use a different strategy, such as providing a text summary beneath a graphic (see “Infographics”). 
• On social media, use detailed image descriptions for images. 
• For logos, a simple identification of the logo will suffice (such as "Acme logo").
• Decorative images, such as spacers, or invisible formatting elements do not need a description and should be marked as decorative so screen readers can skip them.

Examples:

Images of text

Background:

Images of text create barriers for people using screen readers and people with low-vision. When text is presented as an image, screen readers cannot access the text, and users cannot meaningfully magnify the text to improve readability. Browser zoom features will not be able to wrap or enlarge the text in that image. 

Inclusive options:

• Use actual text, HTML data tables, MathML, or other supported languages for text, formulas, and equations. 
• Do not use images of these elements. For example, if you cannot select the text in a table, the table is likely an image and will not be accessible to all readers.

Examples:

Formatting tables

Background:

Data tables are often the most effective way to depict data for people who use screen readers. But poorly formatted tables can create accessibility barriers. When header cells and data cells are properly labeled using a markup language, screen readers can contextualize and interpret the data accurately. Screen readers often struggle with parsing split or merged cells, and nested tables. Keep table structures simple and use clear markup for headers and data cells.

Inclusive options:

• Use markup language to label column and row headers, so screen readers can interpret and contextualize the data. 
• Avoid splitting or merging cells; keep the number of columns and rows consistent through the table. 
• Do not nest tables within tables. 
• See also “Markup languages and Accessible Rich Internet Applications (ARIA) attributes.” 

Color to convey meaning

Background:

For people with color vision deficiency (also called color blindness) and people with low vision, distinguishing certain colors and shades can be difficult, if not impossible. If information is conveyed by color alone, some people may not be able to interpret it. To ensure accessibility, combine the use of color with text, shapes, symbols, or patterns.

When color is used to convey information, such as in heat maps or fluorescent images, choose accessible palettes. For example, perceptually uniform palettes are easier to read than rainbow scales, because they can also be distinguishable for people with color vision deficiency.

Inclusive options:

• Don’t rely on color alone to convey meaning. Combine the use of color with symbols or text. For example, directly label parts of a graphic instead of using a color legend. 
• When using color, choose color combinations that can be distinguished by people with color vision deficiency. Access digital tools like Color Oracle, Coblis, or the Colorblindly extension for Chrome.
• See also “Color contrast” and “Choosing accessible color schemes in data visualizations.”

Examples:

Color contrast

Background:

Color contrast ratio refers to the difference in brightness between two adjacent colors. The Web Content Accessibility Guidelines (WCAG) define minimum contrast ratios that must be met when color differentiation is critical for understanding content. For example: 

• Text should have sufficient contrast against its background
• Non-text elements creitical for comprehension should contrast adequately with their background or adjacent elements.

There are instances when the strict color contrast ratios matter less – for example, when text conveys the same information as the colors (such as labeled pie slices) or when a specific visual presentation is necessary (such as a screenshot).

Inclusive options:

• Ensure text against a background (including text within images) meets the minimum contrast ratio set by the Web Content Accessibility Guidelines (WCAG). 
• Non-text elements essential for understanding, such as graphics and user interface components (e.g., links or social media icons) should also meet WCAG requirements.
• To improve contrast, consider adding a border that contrasts with both adjacent colors (e.g., outlining countries in a map). 
• Certain image types (e.g., heat maps, photos, and screenshots) can be presented in lower contrast to preserve meaning or visual integrity. Consider tools such as ColorBrewer that recommend accessible color palettes for heat maps.
• Two widely used tools for measuring color contrast are: 
  • TPGi’s Colour Contrast Analyzer
  • Web Accessibility in Mind’s Contrast Checker

Example:

Podcasts

Background:

Accessible podcasts means more people can benefit from the information; it also has secondary effects. For example, This American Life, a popular podcast, found that providing transcripts increased web traffic through to better search engine optimization (SEO) and engagement. 

Transcripts are a key element to accessible podcasts. Good transcripts descriptions of sounds like music and background noises. These details help create a similar experience to people listening.  

Clear audio is important too. Soft voices or loud background sounds make it difficult for people who are hard to decipher the information.

Offering podcasts on accessible players and in multiple formats makes it easier for people with disabilities to access them.

Inclusive options:

• Provide a detailed transcript that includes descriptions of sounds. Ensure clear audio that is easy to follow. 
• Offer multiple ways to access the content. For example, provide streaming and downloadable files (like MP3 audio files), since assistve technology can often handle these formats more easily. 
• Host podcasts on platforms that follow accessibility guidelines, including keyboard navigability and proper markup. Some options are AblePlayer or JW Player.  
• See "Keyboard navigability” and “Markup languages and Accessible Rich Internet Applications (ARIA) attributes”. 

Examples:

Videos

Background:

Videos often rely on audio or visuals alone, which can make them inaccessible for people who are deaf, hard of hearing, in noisy environments, low-vision, or blind. Making videos accessible means presenting both visual and audible information in multiple ways. 

Captions, transcripts and audio descriptions are methods of providing access to audio content:

• Captions are time-synchronized text displayed on the video. It includes both dialogue and descriptions of sound effects. Use captions that are large enough (at least 18-point font) and ensure they don’t cover important on-screen information. 
• Transcripts are static (not time-synchronized) and provided as a separate file or webpage. Sometimes time-stamps are included, but this format is more compatible for searching for specific words or phrases than captions. Include thorough transcripts that describe all relevant visual details, including actions that aren’t mentioned in audio. 
• Audio descriptions are spoken descriptions that explain what is happening visually. These can be integrated into the main script or created as a separate audio track. For example: 
  • Integrated into the script: "Now I will pour the polyvinyl alcohol solution and the Borax solution into a cup and mix it with this wooden stick."
  • Separate audio description: (after the line above in the script) "A woman pours two liquids into a cup and stirs them with a wood stick."

Inclusive options:

• Provide captions and transcripts for videos. If actions are not audibly described, include separate or integrated audio descriptions.
• Provide different playback speeds, and don’t employ the autoplay feature. 
• Videos should avoid flashing lights or strobes or warn users before showing them. 
• Use sign language interpretation for live-streamed videos when closed-captioning isn’t available.
• See also, Section508.gov for captions and transcripts guidelines.

Examples:

Emails and newsletters

Background:

Many of the accessibility guidelines for print and digital content also apply to emails. Those principles are summarized in the inclusive options that follow. 

Inclusive options:

• Ensure high color contrast. See also “Color contrast.”
• Avoid using color alone to convey meaning (this includes highlighting portions of text or varying text colors). See also “Color to convey meaning.”
• Use meaningful hyperlink text (not "click here"). See also “Hyperlinks.”
• Add alt text for images, including signature graphics or logos. See also “Alternative text and image descriptions.”
• Include essential information in the email body rather than in separate files, if possible. This can make the information easier to access.
• If using attachments, format them for accessibility.
• Avoid relying solely on bold or underlining for emphasis; screen readers may not interpret that emphasis. 
• Break up long amounts of text with properly formatted headings for new sections instead of bold text.
• Use simple layouts for email body (one or two columns).
• Add sufficient spacing between paragraphs.
• Use plain language when possible. See also “Writing for accessibility.” 
• Avoid flashing images or GIFs; they risk triggering seizures or other conditions. If unavoidable, provide a warning before they appear. See also “Videos.”  

Infographics

Background:

Infographics use images and data visualizations to present complex or dense information in a clear and engaging way. They can pose accessibility challenges if not designed with assistive technologies in mind at the start. Visual cues alone may not work for people who use screen readers or have color vision deficiency (color blindness). Complex layouts can also make the content harder to process for people with cognitive disabilities.

Inclusive options:

• Use fonts that are at least 12-point and a common type face.
• Ensure high color contrast between text, images and data elements and their backgrounds elements (see “Fonts and typefaces” and “Color contrast”)
• Avoid using only color to convey information by combining with text, patterns, or symbols (see “Color to convey meaning”). 
• Choose accessible color palettes and confirm the final project is legible using digital tools. 
• Keep the backgrounds plain to make charts easier to read (see “Posters”).   
• When working on the text, make sure to provide multiple options: 
  • Screen readers can’t interpret infographics if they are presented as images. Create a full text version or an HTML version of the infographic that describes all of the visual and data elements. 
  • Consider placing descriptions on the same page of the infographic or provide a link to the description.
  • Use proper markup so screen readers can identify and navigate the description (see also, “Markup languages and Accessible Rich Internet Applications (ARIA) attributes”).  There are a few options for labeling information about links to longer image descriptions, including the longdesc attribute and <figcaption>.
• Describe the data: 
  • If the infographic is dense with data, provide a labeled table with numerical values either in the document or as part of the text-only version (see also, “Formatting tables”).
  • Make visual cues such as color or icons explicit in the text. For example, if colors represent specific demographic groups, the description should name those groups (see also, "Choosing color to represent people in data visualizations").

Posters

Background:

Many accessibility principles used for online media also apply to printed banners and posters. Apply design principles for scientific posters from the ACS Guide to Scholarly Communication for more guidance.

Inclusive options:

• Use sans serif fonts that are visible from several feet away. 
  • Body text should be 24 – 30-point, 
  • Headings should be 36 – 60-point, and 
  • The title should be 45 – 120-point font, depending on the length.
• Ensure high color contrast between text, images and data elements and their backgrounds elements (see “Fonts and typefaces” and “Color contrast”)
• Avoid using only color to convey information by combining with text, patterns, or symbols (see “Color to convey meaning”). 
• Choose accessible color palettes and confirm the final project is legible using digital tools. 
• Keep the backgrounds plain to make charts easier to read
• If possible, make posters available online, with a QR code or link. Ensure the digital version is accessible. 
• Break text into sections and balance with visuals.
• Leave at least a 1 inch (2.54 cm) margin of whitespace around the edges of the poster. 

Poster sessions and other types of interactive events can be challenging, especially for people that miss social cues or have difficulty hearing or paying attention in noisy environments. While presenting: 

• Offer multiple ways for participants to engage. 
• Keep writing tools nearby so that deaf or hard-of hearing individuals can communicate in noisy environments still.

Emoji and emoticons

Background:

Emoji are pictorial characters, whereas emoticons use combinations of keyboard characters arranged to represent an image —for example, the less-than sign next to the number three to depict a heart (<3). Screen readers often struggle with emoticons because they cannot interpret the series of characters as a single image.

Screen readers translate emoji into text descriptions (e.g., “clapping hands”). Emojis are not always conveyed correctly or as intended, sometimes displaying numeric codes instead of the intended image. 

Using multiple emoji in a row (especially repeating ones) or placing them between words can make messages more difficult to understand. 

Inclusive options:

• Do not overuse emoji in social media posts, and do not use them to replace words. 
• If possible, check screen reader behavior with emoji so that the meaning matches your intent. 
• Place emoji at the end of the message. Make sure essential information is conveyed in text. 
• Avoid using emoticons. 

Example:

Hashtags

Background:

Screen readers read all-lowercase hashtags as one word, which can make them hard to understand.

Inclusive options: 

• Capitalize each word in a hashtag so screen readers can distinguish each word.
• When possible, test out hashtags with a screen reader.

Examples: 

Keyboard navigability

Background: 

Many people use only a keyboard to navigate websites and engage with interactive elements. Others use assistive devices that simulate keyboard commands. Relying on touch screens and point-and-click mouse navigation creates barriers for people using other forms of navigation. Common keyboard strokes for navigation and interaction include Escape, Arrow keys, Spacebar and Tab. The user’s current location on a site should always be clear. For example, highlighting the element in focus helps keyboard users know where they are on the page. 

Providing robust keyboard navigability ensures that interactive elements are usable for everyone. 

Inclusive options: 

• Ensure full keyboard navigability. Websites should support standard keyboard strokes (arrow, escape, or tab key). 
• The current location in the navigation area should be clear to the user through highlighting, and users should always be able to navigate away from a page element with the keyboard.

Markup languages and Accessible Rich Internet Applications (ARIA) attributes

Background: 

Markup languages, such as HTML, dictate the structure and presentation of digital content. They organize information for assistive technologies. For example, using headings allow screen readers to provide users with a quick overview of the information, similar to how a reader might quickly scan headlines. 

ARIA (Accessible Rich Internet Applications) attributes is a set of markup language that makes interactive elements compatible with assistive technologies. ARIA attributes act as a bridge between programming and markup languages, ensuring that elements like buttons, menus or other dynamic content can be announced for screen readers. 

ARIA attributes can also be applied to other interactive elements or elements that change on a screen, and there are many more in-depth descriptions of their functions available online. A note of caution: poorly used ARIA attributes can worsen site navigation. Ensure that pages are well structured, use semantic HTML with ARIA labels to fill remaining gaps.

Inclusive options: 

• Use clear labeling and structure. Ensure that markup languages are organized so screen readers interpret them correctly. 
• Label and tag content consistently. For example, differentiate headings, body text, and other elements with correct tags in all digital contexts. This includes websites, PDF documents, Word and PowerPoint documents, and more. 
• Use ARIA attributes thoughtfully and correctly for non-text elements. 

Example: 

Code for a hamburger button that links to a web page's menu options:

Auditing and Voluntary Product Accessibility Template (VPAT)

Background: 

One website or media development is completed, auditing for accessibility can identify areas that need further addressing. One practical approach is to experience the content the way a disabled people might—for example, navigate through the website using only a keyboard, or activate a screen reader. Solicit feedback from users with disabilities, who are best positioned to evaluate accessibility.

The Voluntary Product Accessibility Template (VPAT) is a widely use tool to assess compliance with Section 508 of the US federal government’s Rehabilitation Act. VPAT is essentially a checklist to evaluate the accessibility of a product. Out of this comes an Accessibility Conformance Report. Although these reports are mostly a requirement of government agencies and some contractors, reliance upon these reports is increasing in academia and other sectors. 

VPAT compliance isn’t absolute. Each criterion on the checklist has degrees of support, ranging from full to partial compliance. The most thorough evaluations employ experts to manually test the content with assistive technologies. Many third-party companies offer VPAT compliance audits, some are automated audits.

Inclusive options: 

• Build accessibility into projects from the start and when possible, audit along the way. 
• If accessibility is a concern, use spot checks (a quick review) to decide whether a full audit is needed. 
• Auditing is particularly important for sites that offer education and critical civic information. Prioritize accordingly. 
• Large organizations with multiple sites should prioritize auditing. 
• Leverage the many auditing tools and services available online to help identify gaps and improve compliance.

Website overlays and widgets

Background:

Some companies offer accessibility overlays—code intended to automatically fix issues on websites without changing the underlying code. But permanent plug-ins currently on the market rarely, if ever, meet the needs of people with disabilities. Over 1000 accessibility experts, software developers and designers, and end users with disabilities have signed an Overlay Fact Sheet recommending  that organizations avoid reliance on overlays as an accessibility solution.

Inclusive options:

• Avoid relying on permanent plug-ins to fix accessibility issues on a website. They often don’t fully address accessibility needs and can sometimes create new barriers or issues. 
• Incorporate best accessibility practices from the start of the development process. 
• Work with accessibility professionals to ensure your content meets the needs of people with disabilities. 
• Provide means for users to contact your organization with accessibility issues or barriers.

Resources on accessibility

• Accessible Social. (accessed January 2, 2026).
• American Chemical Society. Accessibility. ACS Design System. (accessed January 2, 2026). 
• Association of Registered Graphic Designers. AccessAbility2: A Practical Handbook on Accessible Graphic Design. Association of Registered Graphic Designers: Toronto, 2019.
• Center for Plain Language. "Getting started with plain language." (accessed January 2, 2026).
• Chiarella, D.; Yarbrough, J.; Jackson, C.A.-L.; “Using Alt Text to Make Science Twitter More Accessible for People with Visual Impairments.” Nat. Commun. 2020, 11, article no. 5803. https://doi.org/10.1038/s41467-020-19640-w.
• Chartability. (accessed January 2, 2026).
• Evans, M.; “Why and How to Create Accessible Social Media and Website Content.” Feb. 2, 2021.
• George Mason University. AT Resources. Assistive Technology Initiative. (accessed January 12, 2026).
• Harvard University. Content Creators. Digital Accessibility. (accessed January 12, 2026).
• Information Technology Industry Council. VPAT. (accessed January 12, 2026).
• Kaspar, F.; Crameri, F.; “Coloring Chemistry - How Mindful Color Choices Improve Chemical Communication.” Angew Chem., Int. Ed. 2022, 61, 16, e202114910. https://doi.org/10.1002/anie.202114910. 
• Katsnelson, A.; “Colour Me Better: Fixing Figures for Colour Blindness.” Nature. 2021, 598, 224–225. https://doi.org/10.1038/d41586-021-02696-z. 
• Kreckmann, A.; Design Principles for Slide Presentations. The ACS Guide to Scholarly Communication. https://doi.org/10.1021/acsguide.10802.
• Kreckmann, A.; Poster Design Principles. The ACS Guide to Scholarly Communication. https://doi.org/10.1021/acsguide.10702.
• Lawson, B.; “Website Accessibility (15 Best Practices).” WebsiteSetup.
• Mozilla; ARIA - Accessibility. (accessed January 2, 2026).
• Podcast Accessibility. "Accessible Podcast Directory." (accessed Jan 2, 2026).
• University of Washington. "Make Digital Content Accessible." Accessible Technology. (accessed Jan 2, 2026).
• University of Washington. Disabilities, Opportunities, Internetworking, and Technology Center, September 2025.
• Web Accessibility in Mind. WebAIM. (accessed January 2, 2026).
• Web Accessibility in Mind. WebAIM’s WCAG 2 Checklist. Last modified Jun 20, 2024.
• WGBH. Guidelines for Describing STEM Images. (accessed January 2, 2026).
• Wong, L.; “Social Media Accessibility: Inclusive Design Tips for 2024.” Hootsuite, April 24, 2023.
• World Wide Web Consortium. "ARIA Authoring Practices Guide (APG) Home." Web Accessibility Initiative. (accessed January 2, 2026).
• World Wide Web Consortium. "How People with Disabilities Use the Web." Web Accessibility Initiative. Last modified January 2, 2026.
• World Wide Web Consortium. "Tips for Designing." Web Accessibility Initiative.
• World Wide Web Consortium. "Video Captions." Web Accessibility Initiative. 
• World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2. 
• Yale Library. "Academic Poster Resources: Accessibility." (accessed January 2, 2026).