Global Accessibility Awareness Day is May 18. Learn about the digital accessibility solutions and best practices you can adopt today.
Designing for Accessibility- Webcamp
Gain an understanding of accessibility guidance that is relevant in the design process, before development begins. Some considerations are strictly about the appearance of a design (such as color contrast), while some may require the creation of additional designs, or additions to a design, specifically to meet the functional objective.
Accessible Data Tables
Creating accessible data tables for websites is a common challenge that we see across Stanford's digital footprint. This session focuses on how web developers can structure and build accessible data tables using a variety of techniques.
Storyline Accessibility Workshop
This workshop will cover strategies for designing and creating accessible content in Storyline, such as best practices for designing interactive content and integrating media, and implementing accessibility features in the player.
After this session, attendees:
Rise Accessibility Workshop
This workshop will cover strategies for designing and creating accessible content in Rise, such as best practices for using Rise blocks to structure a Rise page. It will also cover how to choose accessible interactive Rise blocks and add alternative text.
After the session, attendees:
Remediating PDF Documents with Equidox
PDF documents on websites and can pose multiple accessibility barriers. Equidox is a web-based PDF remediation tool available to the Stanford community that simplifies the accessibility remediation process for most PDF documents. Additionally, a brief discussion of other PDF remediation strategies will be shared in this session.
After the session, attendees will know:
Not enough time to sit through an accessibility presentation? Want to learn and explore quick accessibility tips in 10 minutes or less? Read on for our Accessibility-in-10-Minutes activities in recognition of Global Accessibility Awareness Day.
The Accessibility-in-10-Minutes activities focus on a variety of digital accessibility topics, from reading about accessibility issues to viewing YouTube videos on assistive technology tools and hands-on exercises for you to complete. All you need is 10 minutes and a Web browser to participate!
Videos and audios intended for university business purposes need to have accurate captions and transcripts respectively.
Your messages need to be communicated accurately to your audience. Only captions transcribed by humans can achieve a high degree of accuracy. Computer-generated (or auto-generated) captions have not reached that level yet. If you see "auto-generated" on YouTube, or if you use Zoom's captions, they are computer-generated captions.
You may do it yourself using the YouTube subtitles editor (which may be exported out to other video players), or pay for a vendor's service. Stanford has negotiated pricing with several captioning vendors.
For more information on captioning, including what to do about captions for live events, see the SODA page on Captions and Audio Descriptions.
People with certain disabilities, whether temporary or permanent, often navigate files and the web using a keyboard. These may be low-vision users, users with limited motor control, or screen reader users. There are also users who find the keyboard more efficient than a mouse or who have broken equipment. Although most of us will never be able to fully grasp the keyboard-only user experience, an important takeaway from this activity is to increase our capacity for understanding and become more sensitive to the keyboard-only user’s experience.
Using only your keyboard, navigate your favorite websites, check and reply to an email, watch a video, or shop online for only 10 minutes a day.
Keyboard Instructions Quick Start:
Press Tab to navigate to the next link, button, or edit field.
Press Shift+Tab to navigate back to the previous link, button, or edit field.
Press Enter or spacebar on a link to open it, activate a button, or open a menu.
Use arrow keys to scroll or move up and down through dropdown options.
Press escape to close dialogs or exit out of a dropdown.
During your scheduled activity time, please attempt the following using the keyboard only:
Navigate through menu options to reach a specific location
Compose an email, run spell check and send
Play a video, pause, and adjust the volume
Respond to prompts like "Accept all cookies"
Close an ad
Consider, do I feel lost or am I confident of my location?
Inclusive design benefits us all. Watch a video or read an article to learn more about keyboard users and navigation:
Color is used on the web to engage users, convey information and enhance design. Although color is beneficial to many users, it can create accessibility barriers for others. Colorblind and other visually impaired users may struggle to read and understand your content if foreground and background colors do not meet the minimum contrast ratio of 4.5:1.
Contrast ratio refers to how bright or dark colors appear on the screen or the luminance of the brighter color to the darker color. Ratios range from 1:1 to 21:1 where the first number refers to the lighter color and the second to the dark color.
A minimum contrast ratio of 4.5:1 is required for normal text and images-as-text against the background color unless the text is Large. Large text passes contrast at 3.1:1 if it is at least 18 points or 14 points and bold.
There are many color contrast resources on the web, Stanford's own Interactive Color Chart Tool is a great place to start on your learning journey and will support you in creating content that is contrast error free.
Let’s try it!
This activity uses colors of the same family to illustrate that:
Using lighter or darker shades may resolve contrast errors against certain background colors.
Some shades of color will pass contrast for Large text only.
You have options! Reevaluating your color palette may not be necessary.
Instructions:
Paste the HEX color values listed below into the "Custom Foreground" field in the contrast check form
Leave "Foreground" and "Background Color" options as "Cardinal"
Press "Go"
Test results load in the "Custom Foreground" column in the chart below
HEX color value: #C5EFF7 - light blue
HEX color value: #66D0E5 - medium blue
HEX color value: #2EBFDC - darker blue
Understanding foreground and background color combination test results:
Text strikethrough indicates the color combination fails contrast
"Large Text Only" indicates the color combination passes contrast for Large text only and includes the ratio for reference
"Passes" indicates the color combination passes contrast minimum requirements and includes the ratio for reference
Continue to test the colors above against different foreground and background colors or use Google Color Picker to generate the HEX values for colors of your choice.
There are many additional resources available, we recommend:
According to the NHIS, about 13% of the population are "low-vision" as opposed to no-vision/blindness. One of the most effective and simplest ways for this population to browse the internet is by using browser zoom to make everything larger. The good news is that testing browser zoom is super easy.
Want to see it in action? Here is a video tutorial for changing your browser’s zoom setting.
The Office of Digital Accessibility team is available to help test web pages for accessibility and provide guidance for developing accessible websites. Reach out to us via our weekly Accessibility Office Hours or a general request for assistance if you have any questions.
Asking questions about accessibility for individuals with disabilities is a critical, and sometimes overlooked, part of the vendor review and procurement process. Whether it’s a simple website, a web-based application, a mobile app, or some other type of electronic content, a vendor may not have the necessary information to share regarding support for accessibility. So, how will you be able to make a good decision? Here are three steps to help get started.
Start by asking a vendor for any accessibility documentation, such as a Voluntary Product Accessibility Template (aka “VPAT”), accessibility conformance report, or third-party accessibility evaluation. The VPAT tends to be the most common and is created by the vendor to document a product’s level of conformance with current accessibility standards. Products change on a regular basis, so be sure to request accessibility documentation that is less than 12 months old.
Start with documentation and then ask questions about how the product supports accessibility. For example, has the vendor evaluated if the product works with a screen-reader (e.g., JAWS, NVDA, VoiceOver, etc.) or ever tested with voice recognition software? Is it possible to use the keyboard only to navigate and interact with all the features?
Asking accessibility questions when conducting a Request for Proposals (RFP) or Request for Information (RFI) can assess not only the accessibility of the digital product, but also the accessibility maturity of a potential vendor, developer, or contractor. See the list of Accessibility Questions for RFPs and RFIs for ideas.
Product demonstrations can provide an up-close view of a product’s functionality and accessibility testing can be part of these presentations. Asking a vendor to demonstrate real-world scenarios while using only the keyboard or with specific assistive technology applications (e.g., a screen-reader), can help identify existing accessibility barriers. This can also be an opportunity to learn if there are potential workarounds or other alternative ways to interact with the website or online application.
The Office of Digital Accessibility team is available to help you review a vendor’s documentation, responses to questions, and understand a product’s level of conformance with established accessibility standards. Reach out to us via our weekly Accessibility Office Hours or general request for assistance if you have any questions.
In November 2009, Google combined their automatic speech recognition (ASR) functionality with YouTube’s captioning support. The intent was to use machine learning and speech recognition algorithms to simplify the creation of captioned videos and provide a scalable solution to making the hundreds of hours of video uploaded to YouTube every minute more accessible. And while early versions of Google’s ASR led to rather spectacular caption failures (the Jamaican Vacation Hoax is still my favorite!), the speech recognition and timing is now far more accurate than ever before.
However, it is still important to verify if the on-screen text is indeed accurate. Captions provide the text equivalent of any spoken dialogue and include other audio information, such as who is speaking and the presence of any meaningful sound effects. And while captions can support access for people who are deaf or hard of hearing, a 2016 Oregon State study found captions can positively impact all students in the classroom environment.
If using the YouTube platform, you can quickly check to see if your video has captions by clicking on the CC button and then looking to see what appears in the upper left corner of the video. If the upper left corner shows the text “English (auto-generated)” as in the example below, then these are captions that were automatically created by YouTube.
But if the text in the upper left corner shows the text “English - Default” as in the next example, then these are captions that have been modified or reviewed and should be accurate.
If you see the “English (auto-generated)” text in the upper left corner of your YouTube video, then you will need to take steps to ensure the captions are accurate.
Captions are more than whether or not there is text on the screen and reviewing whether or not your video has accurate captions is an important step. It is also important to note that even though a video has auto-generated captions, you can still use those auto-generated captions to create an accurate caption file. YouTube has two easy resources to help you with those steps:
The Office of Digital Accessibility website provides additional information on captioning and audio descriptions, including negotiated rates for captioning providers when you want to just outsource that work. Reach out to us via our weekly Accessibility Office Hours or general request for assistance if you have any questions.
A survey of screen reader users conducted by WebAIM found that over 75% felt PDFs are likely or somewhat likely to pose significant accessibility barriers. Creating PDF documents from Microsoft Word that are more accessible starts early in the document authoring process. Two quick steps can include adding headings to provide navigation landmarks for screen reader users and using Microsoft Word’s Accessibility Checker. The Accessibility Checker will scan your document for common accessibility errors and prompt you for the necessary corrections. Once all the accessibility issues have been corrected, you can export a Microsoft Word document as a more accessible PDF version.
Try these accessibility strategies by opening a Microsoft Word document and following the steps listed below. You can also watch this short tutorial video or review this Microsoft Word Accessibility Guide handout (PDF & Word Doc).
Reviewing the presence, order, and nesting of headings on your website is an essential step in making it accessible. Most people browse a site by visiting a page, and scrolling/scanning through it, allowing them to quickly get a sense of the content and what sections they may be interested in. This scanning includes noticing headings, which stand out due to their appearance of being larger, bold, or otherwise visually distinct. Headings help to organize content and make it quick and easy to focus on the parts you are most interested in.
If the headings on your site are properly marked up using heading elements (h1-h6) and properly ordered, this makes it easier for users with disabilities to interact with the site. Correct use of headings will enable screen-reading technology to communicate the heading levels to non-visual users and will allow the headings to still be perceivable if someone uses a custom stylesheet to override yours to better suit their needs.
To check the heading structure on your site you can use several tools, including the Web Developer Toolbar and ANDI.
Visit the Web Developer toolbar page and install the plugin for your preferred browser (supported on Chrome, Firefox, and Opera).
Open the page you want to test in the browser
Activate the Web Developer extension. Go to the Information tab and then choose the “View Document Outline” link.
The outline opens in a new tab. Review the outline and make updates to your content/structure as needed.
Visit the ANDI page and install the bookmark to an easily accessed location, such as the bookmarks toolbar.
Open the page you want to test in the browser.
Activate the bookmark.
Within the tool frame, change the dropdown from “focusable elements” to “structures”.
Expand the “view headings list” to view the outline of headings.
Review the outline and make updates to your content/structure as needed.
Your heading structure is good if:
All headings on your page appear in the outline. If the text was only styled to make it look like a heading, but not coded with a heading element then it will be missing here.
Heading levels are not skipped. The outline view in the Web Developer toolbar will flag missing levels.
The nesting of heading levels makes logical sense. For example, do the headings nested under another one logically serve as subheadings to that parent heading?
When we talk about making a digital property, such as a website or mobile app, accessible, we often talk about it in the context of how well it works with assistive technology. But there is a wide range of assistive technologies that people with disabilities may use, and you may not be familiar with how they actually work. Watch one or more of the following videos to get a better sense of the kinds of technologies that are available, and how they function when being put to use.
Introducing the WCAG 2.1 and 2.2 Accessibility Standards
Purchasing Accessible Technology: Using and Understanding the VPAT
Instructional Accessibility Principles