5. Web Accessibility Policies for Editors and Maintainers

5.1 Accessibility standards and university policy

Web accessibility refers to design approaches which allow web sites to be used by individuals with disabilities, whether visual, auditory, or mobility-related. Those with visual disabilities may use screen readers, such as JAWS, which rely on image descriptions, and a consistent hierarchical structure within web pages for effective access. Those with limited mobility may use a keyboard for navigation, so it is important to confirm that all page functionality is navigable without use of a mouse.

There are two major standards which detail provisions for accessibility: the federal governments Section 508, and the Web Content Accessibility Guidelines (WCAG) 2.0. Failing to meet these guidelines may put the organization at risk of lawsuit. There is general agreement on campus that WCAG 2.0 AA is an appropriate reference standard for web accessibility.

The standards can be perused at the following links. Links to checklists are also included. These checklists are more easily comprehensible digests of each standard.

• WCAG 2.0
  
• WCAG 2.0 Checklist
  
• Section 508
  
• Section 508 Checklist
  
• UChicago Web Services Accessibility Learning Center

5.2 Requirements for Library web sites and software

All new software platforms deployed by the Library which will provide publicly-facing web content must be reviewed by DLDC for compliance with WCAG 2.0. New software to be incorporated into the Library's web site must be compliant with WCAG 2.0 AA. Exemptions are made for vendor provided content such as databases and indexes, but library staff should encourage vendors to deliver interfaces in line with current accessibility standards. Software vendors frequently make inaccurate claims about the accessibility of their products, so please contact DLDC to arrange an accessibility review prior to implementation of new software, rather than after the fact. In cases of large platforms or networks in which the Library participates but does not take ownership (e.g. social media), we encourage use in alignment with Library accessibility best practices to the degree possible.

Examples of library software platforms that may include a web component include software for research guides, room reservations and scheduling, online reference services, blogs, digital collections and exhibits, and data visualization.

The Library is committed to bringing existing web content into compliance with current accessibility standards, as well. A multi-year project is underway to improve accessibility of existing web content.

5.3 Resources and overview

Several online tools which can partially test a page for compliance, such as University of Illinois' FAE and Utah State University's WAVE. These tools are useful for an initial site review, but cannot check for every accessibility requirement. They are useful in checking for issues like compliant encoding of images and forms, but are not always capable of verifying whether a page's overall structure and labeling are standards compliant.

DLDC can provide support in fully reviewing new or updated web content for accessibility compliance. Many accessibility standards can be somewhat ambiguous and are open to interpretation. If it is unclear how to meet accessibility requirements within the context of a particular page or site, please contact DLDC staff for advice.

University of Illinois also provides coding examples for many common web structures and elements. When in doubt, it is worth checking their Center for Information Technology and Web Accessibility site's section on HTML Best Practices for examples.

5.4 Accessibility issues for maintainers and editors

The following are a list of general best practices for generating accessible content on the web.

5.4.1 Title

The <title> element of a webpage is displayed in the browser tab and in search results. The <title> element should be parallel to the <h1> element of the page, although they need not be identical. Both should reflect the primary topic of the page. In Wagtail, the title field will automatically be used to populate both the <title> and <h1> elements, so no special attention is needed to keep them in synch. For site-wide or sectional home pages, the topic may simply be the name of the library (Eg. "The John Crerar Library").

5.4.2 Page Structure (Meaningful Sequence)

To be accessible, a page must be traversable for users who cannot access it visually. Users of screen readers or other assistive technologies may not be able to view visual layout elements such as columns, boxes, tabs, or styled sections. Without these elements, the sequence of page content becomes the most important means of organizing a page.

The best way to ensure a meaningful sequence of page content is to draft the page using an outline, and to allow the nested elements of the outline to define the page structure. Outline levels should be expressed using header elements. Most web content is scanned, rather than read start to finish, and headers provide a means for assistive technology users to skip through the page to seek needed content. The following example shows a well-structured outline for a Library policy page:

5.4.3 Headers

Header elements (<h1> through <h6>) are the primary means used by screen readers to traverse a page's content. Screen readers will typically skip from heading to heading, allowing a user to scan for relevant content. Guidelines for use of headers:

• Headers should not be used to attain a specific text size or visual formatting. CSS should be used for any required presentation characteristics. Editors may contact DLDC for support if specific visual formatting or layout is required for a page.
• The <h1> header should express the primary topic of the page. In most cases, there will not be multiple <h1> elements on a page.
• Headers and intended to be used hierarchically. <h2> should follow <h1>, and <h3>s should be nested within <h2> elements. Maintainers should not skip levels, but should arrange elements in descending incremental order.

Headers in Wagtail

In Wagtail, the <h1> element is automatically created, and elements <h2> to <h5> are available for use by authors. Headings in Wagtail must be correctly nested by authors, as described above.

5.4.4 Tab order

Most web browsers provide a means for any user to traverse interactive parts a page's content using only the keyboard. The sequence encountered through keyboard navigation will typically represent the sequence experienced by users screen readers and assistive technologies. Interactive elements include hypertext links, and web form elements. Maintainers should test the keyboard sequence of their page to ensure that the actual order of elements traversed is logical, and not potentially disorienting. This can be done in most browsers simply by pressing the Tab key repeatedly when viewing a page.

When being browsed this way, most pages should indicate the current selected element with a dotted border. This border is required for accessibility compliance, and if it does not appear, it should be reported to a web editor or DLDC staff.

This method of navigating a page may be used those unable to use a mouse, whether due to visual of movement impairment, or other reason. Blind or other visually impaired users may not be able to use graphical interfaces of a page at all, and may be entirely reliant on tab order to experience a site.

5.4.5 Links & Accessibility

Users should be able to infer the purpose of links, even without visual cues. Sufficient context from surrounding content is acceptable, but the best practice is to have link text itself indicate what it will link to. So rather than "Click Here" or "Link", the text should read "Document Delivery Department" or "Regenstein Floor Plans".

If possible, the same link text should not be repeated multiple times within a single page, unless the link goes to the same destination page in each case. For example, on a list of departments, links to lists of staff should not all be titled "Staff", but rather "Building Services Staff", "Circulation Staff", and so forth.

For information on constructing links in Wagtail, consult the Images, Video, and Links [staff only] documentation.

The destination page has the following HTML to label an anchor within the page content:

5.4.6 Tables and forms

Tables and forms pose some particular accessibility challenges. DLDC does not currently provide tools in Wagtail allowing authors to create tables and forms, though this functionality may be added in the future. If you need to create a table or form, please contact web-admin@lib.uchicago.edu, and DLDC staff will assist.

Earlier documentation regarding accessible tables and forms is still available.

5.4.7 Images

Alt text

This is an alternative to non-textual content in web pages. It is used to succinctly convey the meaning or function of an image or other non-text content. Screen readers typically can read the alt text for users unable to view an image.

Alt text for images is typically a short description (ranging from a single world to a phrase), and may be entered differently depending on the software platform used to create the page (WebExpress, LibGuides, WordPress, etc.). Images within a page may constitute page content, or they may have a function. The alt text need not be lengthy, but should reflect the intent or context in which the image appears. Purely decorative images do not require alt text.

Guidelines for writing alt text:

• Be brief
  • Alt text does not need to include complete sentences, but can be a word or phrase. Only as much text as is needed to convey the image's purpose need be used.
• Avoid redundancy
  • If information is available in the page text, it need not be included in the alt text. Consider a minimal description only if this is the case.
• Consider context
• Be aware of the purpose the image serves within the page. Details of the image unrelated to that purpose need not be mentioned in the alt text.

Alt text in WagTail

For instructions on adding images to pages in Wagtail, and populating the alt text, consult the Images, Videos, and Links documentation.

Alt text in Wordpress

Images are added to WordPress posts via the Add Media button. When an image is uploaded, an "Alternative Text" field appears in the form. If no text is entered here, WordPress will enter the filename as provisional alt text. The alt text may be edited by clicking on an existing image, and clicking the Edit Image button.

Alt text in LibGuides

Images are inserted in the editor with the Insert/Edit Image button. There is an Alt Text field on the form that appears that may be populated. Note that LibGuides does not require that this field be filled, so care must be taken to create alt text for all images requiring it in LibGuides.

Further Resources

Review WebAIM's documentation regarding alt text for further information that what is highlighted in this section.

Images of text

Sometimes image files depicting text are used in logos, page headers, section headers, or other page elements. This is permissible in some cases, but it is preferable to achieve the same presentation using text only. If logos or wordmarks contain graphical elements, than image may remain the best means of formatting them. However, if a logo or wordmark is comprised entirely of text, it is likely possible to duplicate it without the use of images. Using images of text on a page makes it more difficult for screen reader users to access, and also may inconvenience users who wish to copy text to their clipboard.

In recent years, web fonts have become available for many typefaces, and it is possible to add a variety of formatting to web text with CSS (such as colors, drop shadows, gradients, and angled positioning). As a result, it should be relatively rare that an image file needs to be used to present text. DLDC staff are available to advise on approaches to achieve a desired visual effect accessibly.

5.4.8 Deprecated elements

With the adoption of CSS as the primary means of handling visual presentation of web content, several elements have become deprecated. <font> should be avoided, and font styling should instead be handled through CSS. The <b> and <i> elements are deprecated, and have been replaced with <strong> and <em>, which are semantic designations which are more neutral in terms of presentation.