Accessible Technology at Seattle Colleges

Accessible technology has been designed in a way so that it can be accessed by all users. This includes electronic documents, websites, software, hardware, video, audio, and other technologies. People who interact with technology are extremely diverse.

Accessible Technology means a person with a disability is afforded the opportunity to acquire the same information, engage in the same interactions, and use the same services as a person without a disability in an equally effective and integrated manner. A person with a disability should be able to obtain the information as fully, equally, and independently as a person without a disability. Although this might not result in identical ease of use compared to persons without disabilities, it still must ensure equal opportunity to experience the educational benefits and opportunities afforded by the technology.

IT covered by the guidelines includes

• Websites
• Software applications
• Computers and peripherals
• Video and audio content
• Electronic documents

Examples within the above categories include

• Web-based applications
• Learning management systems
• Campus-wide administrative applications
• Content management systems
• Classroom technologies
• Lecture capture solutions
• Cloud-based applications
• Email and calendars
• Library resources

Entities covered by the guidelines include academic, research, administrative, and all other units who support the Colleges’ mission and support services.

In order to assure that websites and web applications are accessible to and usable by everyone, designers and developers must follow web accessibility guidelines. Each of the following topics address issues that are especially common on Seattle Colleges websites.

HTML Headings

HTML headings serve two purposes for non-sighted users:

1. They provide an outline of the page, so users can understand how the page is structured, and how all the sections relate to one another.
2. They provide a target so users can jump from heading to heading with a single keystroke (e.g., the letter “H” in some screen readers)

With the first purpose in mind, headings should be used in proper order whenever possible. That is, you shouldn’t have H2 headings with no parent H1 heading, and all headings should be in order with no heading levels skipped.

Accessible with Keyboard

Many users are physically unable to use a mouse, and might be navigating through the page using keyboard alone. Fortunately testing a website with keyboard is a simple accessibility test that requires no special tools or skills. Just try navigating your website using the keyboard only; don’t touch the mouse. Use the tab key to navigate between features, and other keys if doing so would seem to make sense (e.g., Enter or space to “click” the element that currently has focus, arrow keys to move within a widget such as a menu or slider, escape to close a pop-up window). As you do this, consider these questions:

• Can you access all features?
• Can you operate all controls?
• Is it reasonably easy to tell where you are on the page?

Accessible Images

If web pages include images, the content of those images is, by default, inaccessible to people who are unable to see the images. Whether and how to address this issue depends on the purpose of the image within the context of the web page.

Simple Informative Images

If images are designed to communicate information to the user, they must be described. If they are complex images with a lot of important detail (e.g., graph, chart, diagram) see the next section on Complex Informative Images. In contrast, if images are simple (e.g., logos, buttons, photographs) a short description should be added to the alt attribute of the <img /> element. The description should describe the content of the image as succinctly as possible. The goal is to provide access to the content of the image, without burdening the user with superfluous details.

Complex Informative Images

If images contain a lot of important detail (e.g., graph, chart, diagram) these should include a short title or summary in the alt attribute, but a long description that includes more detail should also be provided. A long description can include any HTML necessary to communicate the content of the image, including data tables.

Historically, the long description has been provided on a separate web page. In HTML5, it is now valid to include a long description on the current page. The longdesc attribute is added to the <img /> element, has a URL as its value, pointing to the location of the description. The URL can point to a separate page, or to the id of a container on the current page. If added to the current page, it is ok to hide the description using CSS display:none.

Screen readers and supporting browsers will inform the user that a long description is available, and the user can choose whether they want to read that description.

Decorative Images

If images are used solely for decorative purposes, they should be added to the page using CSS, not with the HTML <img /> element. If for some reason an image needs to be added using HTML, the <img /> element must have an empty alt attribute (alt=””). This is a standard technique for communicating to screen readers that the image should be ignored.

Accessible Tables

Data tables should not be used to force content into visible columns. This was a frequently abused technique in the past, but multi-column layouts can now be attained using CSS to handle layout and positioning.

That said, data tables are still useful for presenting data in rows and columns. A few specific HTML tags are required in order to ensure that data tables that are accessible to screen reader users. Without these tags, users who are unable to see the table can find it very difficult or impossible to understand the relationships between table headers and the cells within their scope.

The specific tags required depends on whether the table is simple or complex.

Simple Table

A simple table has a single header at the top of each column, and optionally a single header in the first column of each row. It has no nested columns or rows. To make a simple table accessible, apply the following techniques:

• Markup all column headers or row headers as table headers using the element.
• Define the scope of each using the scope attribute (the value of scope can be either “col” or “row”)

Complex Table

A complex table is any table that is not a simple table, as defined in the preceding section. There might be nested rows or columns, or headers might be located in places other than the first row or column. These sorts of tables can be very challenging for screen reader users to understand. To ensure their accessibility, apply the following techniques:

• Markup all column headers or row headers as table headers using the element.
• Add a unique id attribute to each element.
• For every table data cell (), add a headers attribute that lists the id’s of all headers that apply to that particular cell. If more than one header applies to a cell, separate id’s with a space.

When authoring documents using Microsoft Word, Adobe InDesign, or other tools, it’s important to following a few basic steps to assure your document is readable by individuals with disabilities.

The core principles are the same for all document types, but the individual steps vary depending on which tool you’re using and what the final format of the document will be.? The core principles are described below. To learn how to put these principles into practice using specific authoring tools see the list of available guides below or access The University of Washington DOIT Website.  This is great resource to learn how to create accessible documents and videos. The eLearning departments in each college can also assist you in creating accessible course content and creating accessible pages in Canvas.

Use Headings

Headings and subheadings should to be identified as such using the built-in heading features of the authoring tool. Headings should form an outline of the page content (Heading 1 for the main heading, Heading 2 for the first level of sub-headings, Heading 3 for the next level of sub-headings, etc.). This enables screen reader users to understand how the page is organized, and to quickly navigate to content of interest. Most screen readers have features that enable users to jump quickly between headings with a single key-stroke. Virtually every document authoring format includes support for headings and subheadings.

Use Lists

Any content that is organized as a list should be created using the list controls that are provided in document authoring software.? Most authoring tools provide one or more controls for adding unordered lists (with bullets) and ordered lists (with numbers). When lists are explicitly created as lists, this helps screen readers to understand how the content is organized. When screen reader users enter a list, their screen reader informs them that they’re on a list and may also inform them of how many items are in the list, which can be very helpful information when deciding whether to continue reading.

Add Alternate Text for Images

Users who are unable to see images depend on content authors to supplement their images with alternate text, which is often abbreviated “alt text”. The purpose of alt text is to communicate the content of an image to people who can’t see it. The alt text should be succinct, just enough text to communicate the idea without burdening the user with unnecessary detail. When screen readers encounter an image with alt text, they typically announce the image then read the alt text.

Most authoring tools provide a means of adding alternate text to images, usually in a dialog that appears when an image is added, or later within an image properties dialog.

If images are purely decorative and contain no informative content, they do not require a description. However, they may still require specific markup so screen readers know to skip them. The methods for hiding decorative images from screen reader is users is described in more detail in the format-specific pages within this section of the website.

Also, images that require a more lengthy description, such as charts and graphs, may require additional steps beyond adding alt text.

Identify Document Language

Leading screen reader software is multilingual, and can read content in English, Spanish, French, and a wide variety of other languages. In order to ensure that screen readers will read a document using the appropriate language profile, the language of the document must be identified.
You should also identify the language of any content written in a language other than the document’s default language. With this information, supporting screen readers will switch between language profiles as needed on the fly. Most document authoring tools provide a means of identifying the document language as well the language of specific parts.

Use Tables Wisely

Tables in documents are useful for communicating relationships between data, especially where those relationship can be best expressed in a matrix of rows and columns. Tables should not be used to control layout. Authoring tools have other means of doing this, including organizing content into columns.

If your data is best presented in a table, try to keep the table simple. It the table is complex, consider whether you could divide it into multiple smaller tables with a heading above each.

A key to making data tables accessible to screen reader users is to clearly identify column and row headers. Also, if there are nested in columns or rows with multiple headers for each cell, screen readers need to be explicitly informed as to which headers relate to which cells.

• Creating accessible documents in Microsoft Word 
• Creating accessible PDFs from Microsoft Word
• Creating accessible PDFs from Adobe InDesign
• Fixing inaccessible PDFs using Adobe Acrobat Pro
• Creating accessible PDF forms using Adobe Acrobat Pro

Videos should be produced and delivered in ways that ensure that all members of the audience can access their content. An accessible video includes captions, a transcript, and audio description and is delivered in an accessible media player. See below for more details about each of these features.

Captions

Captions are text versions of the audio content, synchronized with the video. They are essential for ensuring your video is accessible to students, employees, and members of the public who are deaf or hard of hearing. They also help non-native English speakers to understand the video, make it possible to search for content within the video, help all students learn the spelling of technical terms spoken in the video, and make it possible to generate an interactive transcript where users can click anywhere in the transcript to watch the video where that text is spoken.

There are two general approaches to captioning video:

Outsource

Companies such as Automatic Sync Technologies, 3PlayMedia, cielo24, and many other captioning service providers will caption videos for a fee. Contact these companies directly for additional information.

Do it yourself

There are free tools available online that make it possible and easy to caption your own video. See Captioning your own video for free for additional information.

The end product generated by both options is a caption file. Most caption files are plain text files with time codes indicating the start and stop times. However, there are various types of caption files with slight variations in their syntax. Once you have a caption file, the final step is to add this file to your video. How you do this, and the types of caption file supported, depends on where your video is hosted.

Audio Description

Audio description is a separate narrative audio track that describes important visual content, making it accessible to people who are unable to see the video. Individuals who are blind can understand much of a video’s content by listening to its audio. However, if a video includes content that is only presented visually (e.g., on-screen text or key actions that are not obvious from the audio) this visual information must be described in order to be accessible to people who are unable to see it.

Like captions, there are two general approaches to producing audio description for video:

Outsource

The American Council of the Blind has compiled a comprehensive list of commercial services for producing audio description. If the video contains a lot of visual information, this may be the best option since describing visual content effectively requires specialized skill. Typically service providers will produce a new video that has the descriptive narration mixed in with the program audio. Then you can provide your video in two formats: One with audio description and one without.

Do it yourself

For videos that have very little visual information, the same free online tools that are used for creating closed caption tracks can be used for creating description tracks. Description tracks are essentially the same as caption tracks—short blocks of text with timestamps that synchronize the text with the video—but their function is different. They are intended to be read aloud by screen readers, rather than voiced by a human narrator. Playing video with text-based audio description requires a media player that supports this feature, such as Able Player, the open source media player developed at the UW. For additional information about free online tools for captioning and describing video, see Captioning your own video for free.

Live Captioning and Description

If live events are simulcast over the Web, live captioning is needed in order to provide access to the audio content for audience members who are deaf or hard of hearing. Similarly, live description may be needed if key visual content will otherwise not be verbalized, such as in a dramatic production. These services are coordinated through the Disability Services Office on each campus. Please contact these offices to learn how to request these services.

Transcript

A transcript is a text version of the media content. A transcript should capture all the spoken audio, plus on-screen text and descriptions of key visual information that wouldn’t otherwise be accessible without seeing the video. Transcripts make video content accessible to everyone, including people who are unable to view the video due to accessibility problems or technical limitations. They are also helpful for people who want to quickly scan or search a video’s content but do not have the time to watch the entire video.

If you have captioned your video, a transcript is available as one of the optional output formats produced by the closed captioning process. This is true of both the free online tools and the commercial service providers. To make the transcript available simply link to it from your web page, wherever you link to or display the associated video.

Able Player, the accessible open source media player developed at the UW, generates an interactive transcript automatically using the caption and/or description tracks. For additional information see the following section.

Choosing an Accessible Media Player

When choosing how to deliver your video, it is important to consider options that are fully accessible. Whether you are selecting a media player plugin or module for your website or selecting a service to host your videos, the following questions should be answered about the available options:

1. Does the media player support closed captions?
2. Does the media player support audio description in a way that enables users to toggle the narration on and off?
   
3. Can the media player’s buttons and controls be operated without a mouse?
   
4. Are the media player’s buttons and controls properly labeled so they can be operated by a blind person using a screen reader?
   
5. Is the media player fully functional, including all of its accessibility features, across platforms and in all major browsers?

One player that satisfies all of these criteria is Able Player, a free, open-source media player that was developed at the UW with accessibility in mind. For additional information see Able Player on Github.

The Seattle Colleges strives to ensure that IT products purchased by, or used at the College are accessible to all faculty, students, and staff, including those with disabilities. To reach this aspirational goal, those responsible for making decisions about which products to procure must consider accessibility as one of the criteria for acquisition. This is especially critical for enterprise-level systems and other technologies that affect a large number of students, faculty, and/or staff. The following three steps provide an example of how accessibility can be considered in the procurement process. Maria Ales (x5446) at Central, Kathleen Chambers (x3681) at North, and Rose Kovolrat (x5137) can assist with any of these steps.

Step 1

Purchasing will request bidders provide information about the accessibility of their products.

Following is an example of accessibility language that could be used in requests for proposals (RFPs):

Mandatory Scored Requirement

Bidder must describe how their IT products or services are accessible to users.

The Seattle Colleges refers to the Web Content Accessibility Guidelines (WCAG) 2.0developed by the World Wide Web Consortium (W3C) Level AA for guidance in meeting its IT accessibility commitments. A checklist for understanding the requirements of WCAG 2.0 Level AA is available at http://www.w3.org/TR/WCAG20/.

If there are issues that prevent Bidder’s IT product or service from meeting these requirements, Bidder must describe efforts underway to address these issues, including anticipated timelines for completion.

Step 2

Evaluators will validate the information provided by bidders and evaluate their products for accessibility.

Vendors should provide detailed information about the accessibility of their product or services. One common method is by providing a Voluntary Product Accessibility Template (VPAT). This is a standard form developed to assist federal agencies in fulfilling their Section 508 requirements. VPATs can sometimes be informative, but they have limitations since they are self-reports completed by the vendors. Some vendors do not have adequate technical expertise to accurately assess their products’ accessibility. Others skillfully complete their VPATs in ways that trivialize the significance of accessibility shortcomings. Therefore, VPAT claims should be independently verified and not accepted at face value. A VPAT could provide a good starting point, but ultimately vendors, particularly those whose products are selected as finalists, should be engaged in a thorough discussion about accessibility of their products.

Few IT products are fully accessible. However, vendors should at a minimum be willing to make a commitment to address their accessibility problems. Without this commitment, using the product may place the College at risk for discriminating against some of its students and/or employees.

Step 3

Purchasing will include accessibility assurances in contracts with vendors when applicable.

If ultimately the best product for meeting a particular need is one that fails to fully meet accessibility requirements, vendors should be asked to make a commitment to improving accessibility over a specified timeline, perhaps working with campus staff.

After a procurer discusses accessibility issues with a vendor, the procurement contract should include language that specifically documents the agreement between vendor and procurer as to how satisfactory progress on accessibility will be measured. For example, the vendor might provide a roadmap as an addendum to the contract with a prioritized list of accessibility issues and a timeline for addressing each issue. Then, contract extensions might be contingent upon satisfactory progress toward resolving the issues identified in the roadmap.

Even if the product is currently accessible, the contract should include language that assures continued accessibility as the product is updated. This is especially important for products that are developed on an ongoing rapid release cycle.

The following checklist is based on the WCAG 2.0 standards, and is provided to assist the Seattle Colleges community, including web designers, developers, content creators, and purchasing agents, in creating and procuring accessible IT.

All Information Technology should be:

• Perceivable
• Operable
• Understandable
• Robust

Vendors and contractors are also expected to use these guidelines when providing products and services to the Seattle Colleges. Many of the items in this checklist apply to web pages and web-based applications as well as electronic documents in Microsoft Word, Adobe PDF, and other formats, and other products and services that are not specifically web-based.

Perceivable

Make content and controls perceivable by all users.

1. Do images have alternative text?
   • More about Making Images Accessible
2. Does video have captions and does audio have a transcript?
   • More about Producing Accessible Multimedia
3. Does the web page or document include headings, lists, ARIA landmarks, and other semantic elements to communicate document structure?
   • More about Providing Structure in Web Pages and Documents
4. Is the tab order and read order logical and intuitive?
   • More about Ensuring Proper Tab and Read Order
5. Do form fields within web pages and documents have appropriately coded labels and prompts?
   • More about Creating Accessible Forms
6. Have you avoided using visual characteristics to communicate information (e.g., “click the circle on the right” or “required fields are in red”)?
   • More about Avoiding Reliance on Visual Characteristics
7. Does the interface have sufficient contrast between text color and background color?
   • More about Providing Sufficient Color Contrast
8. Does the content scale well when text is enlarged up to 200 percent?
   • More about Supporting Enlarged Text

Operable

Make content and controls operable by all users.

1. Can all menus, links, buttons, and other controls be operated by keyboard, to make them accessible to users who are unable to use a mouse?
   • More about Designing for Keyboard Accessibility
2. Does the web page include a visible focus indicator so all users, especially those using a keyboard, can easily track their current position?
   • More about Providing Visible Focus for Keyboard Users
3. Do features that scroll or update automatically (e.g., slideshows, carousels) have prominent accessible controls that enable users to pause or advance these features on their own?
   • More about Ensuring Accessibility of Scrolling or Updating content
4. Do pages that have time limits include mechanisms for adjusting those limits for users who need more time?
   • More about Providing Accessible Time Limits
5. Have you avoided using content that flashes or flickers?
   • More about Avoiding Flashing or Flickering Content
6. Does the web page or document have a title that describes its topic or purpose?
   • More about Providing an Informative Title
7. Are mechanisms in place that allow users to bypass blocks of content (e.g., a “skip to main content” link on a web page or bookmarks in a PDF)?
   • More about Facilitating Efficient Navigation
8. Does the website include two or more ways of finding content, such as a navigation menu, search feature, or site map?
   • More about Providing Multiple Ways of Finding Content
9. Is link text meaningful, independent of context?
   • More about Using Meaningful Link Text

Understandable

Make content and user interfaces understandable to all users.

1. Has the language of the web page or document (or individual parts of a multilingual document) been defined?
   • More about Identifying Language of a Document and its Parts
2. Have you avoided links, controls, or form fields that automatically trigger a change in context?
   • More about Providing Predictable Behavior
3. Does the website include consistent navigation?
   • More about Providing Consistent Site-wide Navigation
4. Do online forms provide helpful, accessible error and verification messages?
   • More about Using Accessible Methods of Form Validation

Robust

Make content robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

1. Is the web page coded using valid HTML?
   • More about Validating Your Code
2. Do rich, dynamic, web interfaces, such as modal windows, drop-down menus, slideshows, and carousels, include ARIA markup?
   • More about Using ARIA for Web Applications

CENTRAL

Room: BE1112
Phone: 206.934.4183
Email: RC.Central@seattlecolleges.edu
Website: https://seattlecentral.edu/campus-life/student-support-and-services/disability-support
WA Relay Service Voice: 1.800.833.6384

NORTH

Room: CC2346A
Phone: 206.934.3697
Email: ds@seattlecolleges.edu
Website: https://northseattle.edu/disability-services

SOUTH

Room: RS12
Phone: 206.934.5137
Email: Access.South@seattlecolleges.edu
Website: https://southseattle.edu/access-services

• Seattle College District Policy 241
  

  Accessible Technology

• Seattle College District Procedure 241
  

  Accessible Technology

• Seattle College District Policy 418
  

  Reasonable Accommodations for Employees and Applicants with Disabilities

• Seattle Colleges Procedure 418
  

  Disability Nondiscrimination and Accommodations for Students with Disabilities

• Seattle Colleges Policy 387
  

  Disability Nondiscrimination and Accommodations for Students with Disabilities

• Seattle Colleges Procedure 387
  

  Disability Nondiscrimination and Accommodations for Students with Disabilities

• Section 504 of the Rehabilitation . . Act of 1973
• Americans with Disabilities Act