These web accessibility tips can be utilized by website specialists, engineers, or content creators to direct them in making or sending online assets that are completely available to all clients. This rundown isn't planned to supplant or guide to formal norms, for example, the Internet Consortium's (W3C's) Internet Content Openness Rules. Do you have any suggestions for how to improve this list? Kindly send your plans to accesscomp@uw.edu.
Use alt text to give people who can't see the images, like people who use screen readers or Braille output devices, access to the content. Alt text is upheld by most report designs, including HTML, Microsoft Word, and Adobe PDF. For more data, see the UW Available Innovation page Making Pictures Open.
Use headings and subheadings to shape a diagram of the page. Try not to skip heading levels. They help non-visual clients (counting web indexes) to comprehend how the page is coordinated, and make it simple for screen peruser clients to explore. For more data, see the UW Available Innovation page Giving Design in Pages and Records.
The only type of PDF that supports headings and alt text for images is the "tagged PDF." Utilize the PDF Availability Checker that is given by Adobe Acrobat. Visit the UW Accessible Technology page Creating Accessible Documents for additional details.
PDFs jam a report's appearance across working frameworks and gadgets. In the event that this trademark isn't fundamental, consider utilizing another arrangement, for example, HTML, which is significantly more available.
The W3C Open Rich Web Applications (ARIA) particular makes it conceivable to deliver available intelligent web applications. One simple section into ARIA is milestone jobs. Users will be able to jump directly to that section of the page with just one keystroke if they simply add an HTML attribute for one of the eight landmark roles (for instance, role="navigation" or role="main"). On the other hand, use HTML semantic components that guide to ARIA jobs. For more data, see the UW Available Innovation page Giving Design in Pages and Records.
Utilize the HTML name component so screen peruser users will realize which labels or prompts are related with which structure fields. For more data, see the UW Open Innovation page Making Available Structures.
PDF symbol: 30_Web_Tips_2023
In HTML, wrap groups of checkboxes or radio buttons in a fieldset element, and wrap the question or prompt that applies to them all in a legend element. For more data, see the UW Open Innovation page Making Available Structures.
Use HTML markup properly to convey relationships among column and row headers and the data cells within their scope. For more data, see the WebAIM article Making Accessible Tables.
Since some screen readers are multi-lingual, use markup to identify the default language of a document and of any text that deviates from the default. For more data, see the UW Open Innovation page Recognizing Language of a Document and its Parts.
Ensure foreground and background have enough contrast. There are many free tools that can assist with this. For more data, see the UW Open Innovation page Providing Adequate Color Contrast.
Since users may be unaware they can increase text size using browser hotkeys, use a reasonably large text size by default; then, users can make it smaller if desired. Note that a text size of 1em equals the default browser text size, therefore is an optimal choice for most text, thus respecting users' preferences and expectations.
Provide plenty of space between lines and blocks of text. This makes text generally easier to read and makes it easier for many users to track text horizontally.
In CSS, use :hover to make the page respond to user's mouse movements. For individuals who aren't using a mouse, provide the same functionality using :focus. For more data, see the UW Open Innovation page Giving Apparent Focus to Keyboard Users.
Use text instead of images of text, and control its appearance using CSS. Images of text become blurry when enlarged, take longer to download, and are inefficient for the site creator to edit.
Keep your content easy to read and understand. Often, web creators use bigger words and longer sentences than are really needed.
Subtitles provide benefits to all users. There are some free, easy-to-use tools available that assist in the most common way of transcribing and subtitling videos. For more information, see the UW Open Innovation page on Making Accessible Videos.
For individuals who can't see video, create a text that includes brief descriptions of significant visual content, then provide that as a separate description track, either as timed text or recorded narration. This format is known as audio description. For more information, see the UW Open Innovation page on Making Accessible Videos, especially the section on Audio Description.
Provide a transcript for video and audio so people who are deaf-blind and those with low internet bandwidth can access the content. Transcripts benefit all users by allowing them to quickly access content.
When selecting a media player, ask questions like: Does this player support closed captions? Does it support description? Can it be operated without a mouse? Are buttons and controls accessible to screen reader users? Accessible Player is a free player created with accessibility in mind by the University of Washington, with assistance from the open-source community.
When creating a navigation menu, ask questions like: Could this menu ever be operated by keyboard alone? If it could, is doing so efficient or does it require dozens or hundreds of keystrokes? Consult reputable resources, such as the WAI-ARIA Authoring Practices for accessible design patterns and examples on how to properly code navigation menus.
An accessible widget uses ARIA to interact with assistive technology (AT), can be operated solely with the keyboard, and gracefully degrades for users who do not have the latest AT. Consult the WAI-ARIA Authoring Practices for accessible design patterns and examples on how to properly code a wide variety of common widgets.
If choosing to use an existing widget instead of creating your own, conduct a reasonable level of testing. Accessibility-related information can be found in the bug reports and documentation. Test widgets using keyboard alone, or using AT, and ask users with disabilities to test them.
Most LMSs and CMSs provide some level of support for accessibility. Understand the accessibility features of the tools you're using. If there are accessibility deficiencies, understand the workarounds. Know which themes, plugins, and modules are accessible, and recommend or require those over inaccessible options.
Take the #nomouse challenge! Try navigating the web page and controlling all of its elements using the tab key on a keyboard; Avoid the mouse. This simple test is often a good indicator of accessibility. For more information, see nomouse.org.
All major operating systems and some web browsers have high contrast color schemes available. Ensure that all essential page content remains visible when these are enabled.
There are free screen readers and other assistive technologies available that can be used for testing. You don't need to become an expert user, but simple tests with assistive technology can provide valuable insights into whether certain features on a page could present accessibility issues. For more information, see the WebAIM article Testing with Screen Readers, as well as their series of quick guides on testing with specific screen readers.
Increasing numbers of users, including users with disabilities, are accessing the web using phones, tablets, and other mobile devices. Test your website using mobile devices, and while doing so, be sure to check for accessibility.
When procuring products from third-party vendors, we rely on those vendors to provide products that work for all users. Always inquire about the accessibility of products, even for minor purchases. For major products, consider adopting a more formal process for addressing accessibility. For more information, see the UW Accessible Technology page on Securing Accessible IT.
If a product is not accessible, avoid acquiring it, using it, or endorsing it. Work to implement policies on your campus that require IT purchases to be accessible. If it is necessary to use an inaccessible product because it is the only option, communicate to the vendor that you expect to purchase an accessible alternative when it becomes available.
There are numerous communities of practice that are collaborating to make the web (and world) more accessible. For example, consider getting involved with the Access Technology Higher Education Network (ATHEN) or EDUCAUSE IT Accessibility Community. Together, we can make a difference.
If you'd like to get in touch or discuss potential collaboration opportunities, feel free to drop me an email at wilsonmuita41@gmail.com. I'm also active on LinkedIn and Facebook, where I share web development insights and updates.
Thank you for visiting my blog, and I hope you find it informative and inspiring. Let's connect and embark on this exciting journey together!