Many web page accessibility problems are best addressed by editing the source code, so an introduction to web page coding is presented here. Also addressed are issues related to graphic images, videos, interactive forms, and mouse-only controls.
The LibGuides system mentioned below is a web-hosting platform used by many libraries to post topic-specific research guides and other content.
The heart of a web page is an HTML file. An HTML file contains only text, and unlike a word processor document in which the formatting codes are hidden, the codes that controls how the web page looks and functions (called "tags") are in the form of text that is interspersed with the content text. The pictures and graphics that appear on a web page are graphic image files, separate from the HTML, that are displayed in the page according to instructions in the HTML tags.
HTML tags begin with the < symbol and end with the > symbol. They are usually used in pairs, marking the beginning and end of where you want the command to be in effect; the closing tag has a slash mark before the tag name. For example, a level 1 heading would be coded as <h1>My Main Heading</h1>. A small number of tags are used singly, such as the line break tag <br /> or the image tag <img /> – these tags are "self-closing" and end with a slash mark. A tag can contain additional commands called "attributes" that control how the tag works. For example, in the image tag <img src="filename" alt="description" />, the src and alt information are attributes.
Web authoring tools usually have a "source" mode that lets you directly edit the HTML code. In LibGuides, you can use the Rich Text Editor in Source mode. You can also choose the HTML option from the editing menu in the lower right corner of each box. In Edublogs, the library's blog platform, click on Edit Post at the top of the screen.
A text file is a type of computer file containing plain text – characters, spaces, and line breaks – without formatting. Many different text editing programs like Notepad (Windows) or TextEdit (Mac) can open and edit them. HTML files, CSS files, and JavaScript files are text files.
Visual formatting is controlled by CSS (Cascading Style Sheets). CSS is a set of commands that can control aspects of appearance such as color, size, background, and borders. CSS can also control positioning. CSS can create graphic-like effects without using graphic image files, such as by putting words in large letters on a colored background with rounded corners. This technique for creating visual emphasis is inherently accessible.
CSS commands are often contained in a separate file from the HTML for reasons of efficiency, but they could be included in the HTML file, and they could be used in individual HTML tags. In LibGuides, the "Look and Feel" section under the Admin menu has a place where you can enter custom CSS to apply to your guides.
Below is the code that generated the green box above: A "div" (division) is basically a box. "Float" makes the div move to the right or left. "Padding" sets aside space around the inside of the box so the white text don't touch the sides. "Margin" is space on the outside of the div, in this case keeping the surrounding text from touching the left edge. Also defined in this example is the width of the div, the size of the font, the spacing of the lines of text, the color of the text and the background, and the rounded corners.
A scripting language like JavaScript can add functionality to a web page. A script can have accessibility implications that have to be addressed:
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a technical specification from W3C that provides tools that compensate for accessibility shortcomings in HTML and scripts. ARIA tags can be used to do things like identify relationships between objects on web forms, or supply information to support adaptive technology. This article gives an overview of ARIA.
A great place to learn more about HTML, CSS, and scripting languages is W3Schools.
The opening tags for headings are <h1>, <h2>, <h3> ... <h6>.
LibGuides uses Heading 1 for the guide name and Heading 2 for box names, so their Rich Text editing interface offers Heading 3 through Heading 6 in the Format Paragraph menu (second menu from the left). Be aware that in LibGuides, the Rich Text editor is not truly WYSIWYG, and headings might not appear as they do on the actual page.
Paragraphs begin with <p> and end with </p>. Web authoring tools will usually automatically generate these tags when you press the Enter key to start a new paragraph.
In LibGuides, if you press Enter, but don't type anything into the next paragraph, a non-breaking space code ( ) will be inserted between the <p> & </p> tags, resulting in a blank line being displayed. This is usually the cause of unwanted blank space at the bottom of a guide box.
There are three types of list:
The LibGuides Rich Text editor has buttons for creating ordered and unordered lists. To create a definition list, you will need to manually edit the HTML source code.
Tables are best used for presenting data. Using tables as a positioning tool to lock objects into a grid can cause confusion when described by a screen reader.
A phrase that identifies or describes the table should be enclosed in <caption> and </caption> tags, and should be immediately after the opening <table> tag. You can use CSS properties to control how they look, including text-align to control horizontal position and caption-side to control whether the caption appears on the top or the bottom of the table.
Table header tags, <th> and </th>, should be used to mark the headers that label the type of data in the table columns or rows. This allows screen readers to present data in context with their labels. See WebAIM and W3C-WAI for guidance in coding the headers for situations like headers spanning multiple columns or rows, or multilevel headers.
These techniques have broad applicability in addressing accessibility problems.
An ID attribute, in the form id="name" can be inserted into an HTML tag to give that element a unique identity on that page. The ID name can only be used once on the page, and it can't start with a number. An ID can be used to do things like target the action of CSS or a script. In dealing with accessibility issues, an ID attribute enables linking to a particular point on the page, and be used in linking form inputs (text fields, check boxes, buttons, etc.) to their labels.
Links and other text can be visibly hidden for aesthetic reasons, while still be readable by screen readers. This can be done to implement aids for users of screen readers, such as links to move around a complex page, or links to alternative representations of content. Some of these may be useful to people who can't use a mouse; consider making them visible on receiving keyboard focus by using the :focus pseudo-class selector.
See this page from WebAIM for techniques for hiding content.
Special characters can be entered through the HTML editor. Below are the accepted codes for entering diacritics for the Hawaiian language. Also shown are a few other useful characters. Each starts with an ampersand and ends with a semicolon. Because the ampersand has a special function, you should use the & string if you are editing HTML source code and you want to display an actual ampersand character. In the LibGuides Rich Text editor, you can just type the &.
| Character | HTML Code |
|---|---|
| Ā | Ā |
| ā | ā |
| Ē | Ē |
| ē | ē |
| Ī | Ī |
| ī | ī |
| Ō | Ō |
| ō | ō |
| Ū | Ū |
| ū | ū |
| ʻokina | ʻ |
| Character | HTML Code |
|---|---|
| & | & |
| ¢ | ¢ |
| – (n-dash) | – |
| — (m-dash) | — |
| non-breaking space | |
Other special character codes can be found from many sources, including W3Schools and W3C.
The ʻokina is known to throw off screen reading programs that read out text for blind people. To address this, the University of Hawaiʻi Office of Communications recommends using the aria-label attribute within a span tag to supply the word (without diacritical marks) to the screen reader.
The HTML coding looks like this:
Because users of screen readers may skim through a page by jumping from link to link, you should make link text descriptive. Avoid links that merely say "click here".
Having a link open a new tab or window can cause hardship for someone with visual or physical disabilities. It can be disorienting, you can't use the Back function to retrace your steps, and some may experience difficulty switching or navigating tabs. Avoid creating links that open new tabs whenever possible. It's easy enough for a sighted person using a mouse to force a link to open a new tab, but it's difficult to force a link that's hard-coded to open a new tab to open in the same tab.
It's now recommended to give users a warning when a link is configured to open a new tab. You can do it with a symbol or a message like "(opens new window)" at the end of the link. W3C's page on this topic(opens new window) gives a technique for making an "opens new window" message appear only when the mouse pointer hovers over the link or if the Tab key is used to get to the link. Libraries using LibGuides can follow these directions for implementing this technique.
Any graphic image that is used to convey information or has some function needs to have alternative text to describe its content or function.
Graphic images are placed on a web page by image tags. Every image tag needs to have an alt attribute. The alt attribute for any significant image should contain a brief line of descriptive text, ideally no longer than 100 characters. Images that are purely decorative or superfluous should have an empty alt attribute (alt="") to signal to the screen reader that the image can safely be ignored.
Note that an image that is used as a link, and is the only thing in the link, must have descriptive alt text to indicate its destination or function.
For an image that is too complex ot be described by a short phrase or sentence, you could use the accompanying text to address some of the details, or you could link to a detailed description elsewhere on the page or on another page. A longdesc attribute in the image tag (longdesc="URL") can be used to link to a description, but because not all browsers and screen readers support longdesc well, it's recommended to also have a simple link next to or below the image. A long description formatted as a simple web page with appropriate markup can be communicated more effectively than a long string of words.
Click on the "Accessible text" link below the graphic to view the alternative text page.
Graphic images or videos that flash prominently at a rate of 3 times per second or faster can cause seizures in those with photosensitive epilepsy, especially if the flashing contains the color red. Also be aware that some moving images can induce nausea and dizziness. Read more in WebAIM's article on seizure disorders.
Relying solely on color to communicate information can make content inaccessible to people with color blindness. When creating charts, graphs, and diagrams, include labels, notes, and other text as necessary to convey the content, or use accompanying text with your image. Don't rely on alt text to address this because a color blind person looking at a regular browser won't see the alt text (although as with all graphic images, do include an alt attribute and provide alternative text when necessary).
See the library's 2018 (or later) user survey results as an example of what can be done to address this kind of problem. The original pie charts from Google Forms were graphic images that included the pie and a legend that identified what each color corresponded to. To make it accessible, new graphics of only the pie charts were isolated from the original graphic. The legend was replaced by an unordered list, with the percentages added to category names. The bullets were styled as colored dots matching the chart. Since all the information was now in the legend, the pie charts were redundant and were given empty alt attributes. The bar charts were recreated with CSS, and use no graphic images.
YouTube now attempts automatic captioning on all uploaded videos. Once you upload a video, allow time for processing (it could take hours for a longer video). The captions will be listed in the Subtitles interface if YouTube was able to generate captions. You can then edit them to correct errors, adjust timing, and make other refinements.
You may find that the "Transcribe and Auto-Sync" option is easier to use. You can prepare the caption text in a word processor and copy and paste it into the text entry box; the timing of the captions will be set automatically. Unpublish the automatic captions so that they are not presented to viewers as an option.
You can add additional text to describe other significant sounds (example – [phone ringing] ) or to identify who is speaking (example.– >>Rick: Play it, Sam.)
I recorded a captioning demonstration for my accessibility presentation at the 2021 HLA + PIALA Joint Annual Conference.
Providing a transcript makes the content available to people who cannot get it from viewing the video. In addition to spoken content, you can also describe key visual content in the transcript.
Audio Description is an additional audio track in which a narrator describes key visual content to allow people with visual impairment to understand what is happening in a video.
Update Nov 2023: YouTube recently launched an Audio Description capability. It is not yet available to all creators.
When creating instructional video content, you should try to avoid conveying information in a purely visual way. For example, if you demonstrate a database search with screen-captured video, you can record a narration that includes enough detail that a blind person can understand the key points.
For more information about these topics, see WebAIM's article on captioning, transcripts, and audio description.
Widgets that you embed into your web page may have accessibility issues of this nature.
Web forms (e.g., check boxes, radio buttons, text fields) are often laid out in a manner in which the labels are to the right of the thing being labelled, which is understandable visually, but confusing when a screen reader reads the form from left to right. Therefore, form elements should be linked to their labels using the <label> tag or the aria-label and aria-labelledby attributes. Assigning ID attribute names to form elements or labels (or using IDs that already exist) allow you create these links.
Using JavaScript to manage form data can cause accessibility problems. You should test forms to make sure you can fill them out using only the keyboard.
For more information, see http://webaim.org/techniques/forms
Declaring the language of a web page or part of a page helps adaptive technology to properly present the page content, and can also have implications for searching and display. The primary language of the page should be indicated in the <html> tag near the top of the document with the lang attribute – <html lang="en-US"> for US-style English.
Web hosting platforms might or might not allow languages to be declared for individual pages within a website. For example, for some LibGuides sites, the language declaration is the same on all pages. However, the lang attribute can be applied to any HTML element, so we can use it in <div>, <span>, and <p> tags to declare a language for part of a web page. Language codes are defined in the ISO 639 standard.
In Google Sites and Google Forms, there appears to be no way to declare a language for the document. Google Sites pages and Google Forms will always trigger an alert on accessibility checkers.
Many websites have extensive navigation links or menus near the top of the page. To spare screen reader users from having to listen to the navigation links being read out every time they open a page, a hidden "skip navigation" link can be placed at the top of the page that takes the user down to the place in the page where the actual page content begins, This technique can be applied to other parts of the page to aid navigation. LibGuides has a skip link on each page; you'll see it pop into view if you press the Tab key before you do anything else on the page.
You can hide the skip links, but should consider whether they may be useful to people who can't use a mouse. Use an ID attribute to define the location where the link goes to.
The coding for skip link could look like this:
This is the link:
<a href="#listofservices">Skip to the list of services</a>
This is the target:
<div id="listofservices">Our services...</div>
Widgets that you embed into your web page may have accessibility issues of this nature.
Things that can accept user input on a web page, like links, buttons, form fields, and other designated objects, can have a state known as "focus", in which keyboard input will be accepted or will trigger an action. Only one object has focus at a time. You can use the Tab key to switch focus from object to object, generally in the order in which they occur in the page code (or Shift-Tab to step through them in the other direction). This functionality is important for people who have difficulty using a mouse and have to rely on the keyboard or other adaptive device.
Implications for Accessibility:
Most institutions follow the WCAG 2.0 Level AA standard for web accessibility.
Information about the University of Hawaiʻi's Voluntary Resolution Agreement with the US DOE's Office for Civil Rights and its accessibility compliance efforts.
You can check a web page with the WAVE tool by entering the URL at the WAVE website. You can also install a Chrome or Firefox extension that lets you click a button to run a check.
WAVE shows you errors, alerts, and features on the page. The Styles Off view shows you how the page looks when it's stripped of its CSS formatting, which can help you understand how someone using adaptive technology might experience the content of the page. The Contrast tool helps you choose text and background colors to have have adequate contrast.
Other accessibility checkers include:
Sometimes the best solution to an accessibility problem is to provide an alternative web page that provides the same information or functionality in a different manner.
Even when you are able to fix specific accessibility problems, the solution might not be as user friendly as having something presented in a more straightforward layout. Examples of alternative presentations:
When web browsers render HTML files into web pages, multiple spaces in the HTML code are treated as a single space, and line breaks in the code (created by pressing the Enter key) are treated as spaces. So when you are directly editing HTML source code, you can use spaces and line breaks to make the code easier to read, without affecting the appearance of the rendered web page.
HTML has a comment tag. Anything enclosed within <!-- (left angle-bracket, exclamation point, and two hyphens) and --> (two hyphens and a right angle-bracket) are ignored by the web browser. You can use this to leave a note within the code that may be useful in future editing, You can also use it to hide or disable something without erasing it.
