Presentation Summaries

The paragraphs that follow summarize the content of presentations given at the workshop. The presentation slides are available online in a public Google Slides deck.

CS0 Class at Furman University – Paula Gabber

At Furman University, each section of CS0 is focused on a particular topic such as social media, multimedia, games and artificial intelligence, virtual worlds and simulation, and cryptography. One section focuses on accessible technology. As a liberal arts college, Furman hosts these specific topics to help grab the attention of students who might not otherwise take a CS course or major in CS. CS0 fulfills a general education requirement for math and formal reasoning, which also helps attract students to the course. I developed the accessible technology section of CS0 after coming back to teaching from serving as dean and overseeing the accessibility office. Because it is a CS0 class, we are hoping to give students the seeds to get interested in accessibility and hopefully revisit the topic in later CS classes.

The primary objectives of the course are to

  • motivate understanding and empathy for disability,
  • introduce accessibility issues within core CS topics,
  • engage in interdisciplinary dialogue about accessible technology, and
  • cover core CS topics needed for new majors as well as general education requirements.

The course serves as an introduction to a variety of accessible technology options and builds the infrastructure for more robust content provided in subsequent classes. Students develop an appreciation for the challenges facing computer scientists when creating, testing, and maintaining technology and digital content.

During class sessions, we have discussions based on readings and videos on the following topics:

  • What must occur for a person with ____ disability to have access to ____ information at the same time and same cost as someone without a disability?
  • What business/institution might benefit from making ____ information accessible?
  • What human or civil right is violated when ____ information is not accessible?
  • What are the advantages and disadvantages of relying on public funding to support and develop accessible technology?

Because the students come from a variety of majors, they bring a variety of perspectives to these conversations.

During the section on operating systems, we talk about accessibility features of the MacOS. Throughout the section on networks and the Internet, we learn about the Web Content Accessibility Guidelines (WCAG) and read from Disability, Human Rights, and Information Technology edited by Jonathan Lazar and Michael Ashley Stein. In the section on algorithms and programming, students learn about Python libraries for speech recognition and text to speech. During the section on graphics, students learn about social networking environments, specifically focusing on the use of Second Life by autistic individuals.

Resources we use include the following:

Birmingham-Southern College CS0 – Amber Wagner

At Birmingham-Southern College, CS0 is an intro course for majors and non-majors that follows the Advanced Placement (AP) Computer Science Principles curriculum. Previously, this was known on campus as an easy class, but we want to ensure the content is meaningful to participants. I’ve included a lecture on accessibility where we talk about the impact technology can have on a person’s life, types of disabilities and their effects, the Americans with Disabilities Act, and assistive technology (e.g., screen readers, magnifiers, speech systems, braille technologies, eye tracking, track pads).

We have also created activities focused on accessibility. In one activity, students break into pairs and give their partners directions to the cafeteria without referencing any visual cues. Once they get in the cafeteria, they must use an unusual water fountain that is there. This leads to a discussion about design that focuses on topics like Norman Doors, which are doors designed in a way that it is hard to tell whether to push or pull. In a second activity, students learn about hearing loss through a hearing loss simulator, a video about lip reading, and an activity called “Look, smile, chat.” I hope to implement activities with speech to text in the future.

I’ve also implemented activities in other CS classes. In our CS1 class, we have activities where we discuss the need for clear prompts to the user. Students critique one another’s projects for clarity and usability. In our human computer interaction/software engineering class, students tour an organization that works with people with disabilities and learn about the design of Myna, a vocal user interface for block-based programming. They then engage in projects.

Accessibility Peer Review: A Team Activity for Software Dev Students – Tina Ostrander, Green River College

Green River College offers a four-year degree in software development. Third-year students take a series of web programming courses. Fourth-year students complete a two-quarter capstone sequence. The students work in Agile teams to develop real-world software.

Students learn about accessibility throughout the curriculum rather than just as a special topic or lecture. Second-year students learn the importance of valid HTML and semantic markup. Third-year students read Don’t Make Me Think: A Common Sense Approach to Web Usability, perform usability reviews every two weeks, and learn about form design. Fourth-year students continue performing usability reviews and then participate in an accessibility peer review. Student teams play “accessibility consultants” to review another teams’ products and make recommendations. Teams then reflect on the recommendations and make improvements to their software products.

Before peer reviews, students watch a short video by WebAim (0:21-1:15), see an overview of accessibility, and read Google’s How to Do an Accessibility Review. The day of the review, students pair up or rotate teams and use an Accessibility Peer Review handout as a checklist. Student teams complete these tasks:

  1. Check for valid HTML using the Validator.nu HTML5 Validator.
  2. Run an accessibility check using the WAVE website or WAVE plugin for Chrome.
  3. Run an accessibility audit using Chrome Web Developer’s Audit tool (Instructions).
  4. Try to fill out a web form using only a keyboard (no mouse).
  5. Test for colorblindness using a tool like the Chrome plug-in: I want to see like the colour blind.
  6. Access the site via a screen reader to see if you can navigate the site using only voice.

Student teams document results for each step, and make suggestions and recommendations.

Teams have one week to respond to the following:

  • What recommendations did you receive? Which of those recommendations do you plan to address, and when? What recommendations do you plan to ignore, and why?
  • Add a user story to your sprint plan that involves accessibility.
  • Summarize what you learned about accessibility, in general. Why is it important? Will this exercise change how you view software design?

Students find the activities useful and say they’ll use what they learned in the future.

Web + accessibility – Becky Grasser, Lakeland Community College

Web Programming I is a second semester course in our four-semester program at Lakeland Community College. We have small classes with diverse students. Students are primarily graphic designers and front-end web developers—not programmers. As their medium is visual, they are not used to talking about individuals who cannot see. An interesting motivation is that if they want to sell their work, they cannot cut out a large portion of their potential audience. Course work is done using a plain text editor (e.g., Notepad++ or Text Wrangler) so that the students are comfortable with writing code before they use a full-featured editor.

Students are required to complete two tasks for every web page they create:

  1. All HTML and CSS must be valid. Students check via the W3C Markup Validator and CSS Validation Service. These validators are free and students can upload the files without the need for a live website. There are a few issues however: the messages can be cryptic, changing W3C standards/guidelines aren’t always updated, and students perceive the systems as too picky.
  2. All pages must be validated for accessibility. Some students do not understand that just because they can use the site, doesn’t mean that everyone else can. Students use the aXe plugin for Chrome. This is a free tool that works with files as well as online pages and links to mostly good explanations of issues. Deque has a good resource on aXe. The tool looks to ensure that headings are used correctly, images have alt tags and titles, form elements have labels, color contrast is sufficient, and similar accessibility issues. Because it’s a new concept for many students, the error messages can be cryptic and confusing.

Each of the first eight (out of 15) weekly assignments has an instructor-produced video that guides them through each of the tools used to check the site. The students can see potential problems and how they are fixed. If the student reads and then watches the video, their scores usually improve each week.

CSE 154 – Web Programming: How Small Changes Can Make a Big Difference – Lauren Bricker, UW

CSE 154 at the University of Washington had an enrollment of less than 150 students in fall quarter and 250-300 students in spring quarter. Student characteristics are diverse, ranging from first year students (in spring quarter), sophomore to senior students, graduate students, and non-matriculated retirees. There are both pre-majors in the class and students who are looking for distribution credits. The course has a prerequisite of CSE 142 - Intro to Programming in Java or CSE 160 - Intro to Programming in Python. The course is a full-stack course that teaches content (words and images), structure (HTML), style (CSS), behavior (Javascript), and communication (server programs). I inherited the course when I came to UW. At the time, the class was about ten-years old and a bit static.

In fall 2017, I observed the class taught by a graduate student named Kyle Thayer. He added content about accessible design as lecture 27 of 30. There were 12 slides based on content from Richard Ladner, Jacob Wobbrock, and Amy J. Ko, and covering the following topics:

  • Types of disabilities
  • Temporary and situational disability
  • What is accessible design?
  • Experiencing a phone’s screen reader
  • Definitions of universal design and ability-based design
  • Ability-based design principles
  • Accessible web design principles
  • Tools and resources

In spring 2018, this content was moved to lecture two of the course and reduced to nine slides that fit well within a lecture on HTML. Information on ability-based design was removed, and we added more tools and resources. We immediately used this to motivate the use of accessible web design principles:

  • Use document structure tags: e.g., <article>, <strong> as opposed to deprecated style tags like <b>.
  • Provide metadata: e.g., <html lang="en">.
  • Provide alternatives: e.g., img alt tag, video captions, and an interface that allow both keyboard and mouse input.
  • Avoid directional text: e.g., "the diagram on the right shows..."
  • Make sure your page validates.

In fall 2018, we continued to iterate. We added pre-lecture readings and more resources and worked to better connect accessibility and semantic tags. We pointed students to resources from The A11y project and a Web Accessibility Workshop from Grace Hopper.

Anecdotally, students better understood how the accessibility information related to the goals of the course when it was connected with the “interface” of a webpage and the HTML/CSS. Teaching assistants found students were more compliant about including alt information in their image tags. Students were more willing to use <section> and <article> vs overuse of <div>.

For spring 2019, we will continue to iterate by

  • Including even more motivation and demos on using proper HTML tags,
  • Using ARIA attributes,
  • Showing the Chrome Inspector Audit tool for accessibility,
  • Showing students how to check the contrast ratio, and
  • Making our course website site, slides, and assignment products accessible.

Mobile App Accessibility Assessment: Promoting a social model of disability among engineering students – Anat Caspi, UW and Cecilia Yang, Mt Holyoke College

As an REU (Research Experiences for Undergraduates) student at the UW over summer 2018, Cecilia worked on a mobile app accessibility assessment tool that Anat used in her accessibility capstone course to promote a social model of disability among students learning about accessible technology. UW’s Taskar Center for Accessible Technology (TCAT) has an academic mission to promote the use of accessible design best practices in engineering. TCAT’s focus on deployment and translation puts us on a unique path with its own demands. At the core of working on accessibility is the understanding that as engineers we should always be mindful of the extremely heterogeneous and diverse needs and requirements that people present as users. In all of our projects, we work with community members as co-designers and also work in a very interdisciplinary way. The bottom line is that we have cultivated communities of practice that include people of all abilities and ages, including caregivers, therapists, and practitioners, who engage regularly with our students through our projects.

We address accessibility as an issue pervasive to usability in all of engineering and design rather than addressing it as a specialty subfield. This is very important as we pursue an understanding among our students not only that accessibility is important, but that it is deeply connected to the fact that our built environment and our technology environments have traditionally been built in a mismatched manner to the majority of people. For inclusive design to be done appropriately and ethically, we have to see the fault in building mismatched products and environments, rather than trying to fix or ameliorate the deficiencies of a particular population. Broadly, this is the social model of disability, which doesn’t address people as if they are coming in with some kind of a deficit—rather, we are correcting designs that were poorly engineered by not having taken people’s bodies or abilities into consideration. Therefore, accessibility is construed as designing technology for the entirety of the human experience, a skill that is valuable regardless of the academic and career paths students choose.

Our Accessibility Capstone course provides students with the following:

  • Exposure to the design, economic, and social challenges that engineers face in the design, development, and use of accessible technology. And if your ears perked up, then YES, a subtext here is that engineers and designers can be and are themselves possible users of accessible technologies, going back to our co-design processes.
  • Engagement in a team-based project experience, where the teams use a rigorous engineering design process to tackle mismatches between built technologies and their use by individuals of all abilities.
     
  • Participation and Interaction with Needs Experts who are users of accessibility features and assistive technology in the local community along with health care professionals, coaches, and caregivers.

As you can imagine, it takes a lot of effort to build the kinds of relationships and communities that can support student teams in this learning process. Also, we ensure that our students are not just dropped into the interaction, but are properly trained.

We run a pre-capstone accessibility seminar that requires students to

  • think critically about the complex relationship between technology and diverse abilities;
  • communicate effectively about diverse abilities and about design process; and   
  • apply design and engineering skills in participatory design environments to create technology solutions that improve quality of life, but also enhance agency, flexibility and control.

By using the Mobile App Accessibility Assessment as a learning tool, we aim to ensure students

  • understand different ways a technology may mismatch its users,
  • develop empathy without using simulation,
  • understand principles of universal design,
  • are able to design and utilize unit tests and user testing to assess and improve accessibility, and
  • enhance their own critical thinking and communication skills in discussing user interaction and accessibility.

In a pilot experiment, undergraduate students majoring in computational, design, and engineering fields were divided into two groups. One group reviewed one mobile app together and used the Mobile App Accessibility Assessment, contributing their review to a repository. The other group attended two lectures about universal access to mobile devices, had a reading assignment on the topic, and then performed the assessment. Both groups indicated that overall the assessment was of value to them and both indicated that it increased their commitment to engineering and designing accessible products. All participants expressed interest in educating other people on accessibility issues. When asked about their biggest takeaway, all responses from the second group focused on mobile application engineering and accessible app development. Responses from the first group were more varied with responses indicating helplessness about disability, the plight of the disabled, or the ability of the developers to create or break accessibility.

The Mobile Application Accessibility Assessment is a survey tool that can be used by novice users (people unfamiliar with accessibility features on mobile devices) to generate useful reporting structure and infographics to provide actionable information for developers and end users. The tool should assess whether a specific mobile app is accessible to different types of users, whether it is interoperable with accessibility features, and whether all the functions be reached and performed smoothly and equitably. We focused on two accessibility features: VoiceOver and Switch Control. The tool explains two categories of interaction elements where accessibility gaps occur: elements for perception that contain information but do not allow further actions and elements for manipulation that allow users to perform an action. Reports from the tool quantify the information from the survey and are organized by accessibility feature and its interoperability with the app. Inherent to the report is a social model of disability, which views using accessibility features as an alternative method of experiencing applications, as opposed to an inferior choice caused by the user’s deficiency. Future work will create an updatable repository of app assessments and open-source the assessment tool and learning materials.

Capstone Projects: Accessibility by and for deaf – Raja Kushalnagar, Gallaudet University

Gallaudet University is a federally chartered private university for deaf or hard of hearing students located in Washington, D.C. We offer a bachelor’s degree in information technology (IT) that includes coursework on apps, web development, databases, and security. Students also complete a two-semester capstone sequence. Even though our students are deaf, that doesn’t necessarily mean that they are savvy about accessibility. Our students participate in self-reflection on accessibility for individuals who are deaf or hard of hearing; self-advocacy and teamwork on incorporating accessibility in IT, and discuss accessibility in IT courses related to apps and the web. Seniors build accessible technology capstone projects. 

In ITS 371 Human Computer Interaction, students are exposed to definitions of accessibility, history of (in)accessibility, accessible technologies, universal design, and experience UI/UX as both customers and developers. In the first semester of the capstone, all Department of Science, Technology, and Mathematics (STM) majors work together to create an interactive STM demo on a website or app for both hearing audiences and deaf audiences. In the second semester, IT majors work together to create a website, app, or device for campus accessibility, business case to the campus admin, or compete with other deaf teams at Gallaudet and the Rochester Institute of Technology/National Technical Institute for the Deaf. Past projects have included (1) captions that indicate who is speaking using Microsoft Connect and (2) video the focuses on the current individual signing much like many teleconferencing systems focus on the person speaking.

Accessibility in Capstones at University of Southern California – Kendra Walther, University of Southern California

In the Information Technology Program in the University of Southern California’s Viterbi School of Engineering, our classes are a cross-section of students from across campus. I like to use videos related to disability and accessibility to serve as inspiration for students and help them develop an understanding of the issues. Here are some videos I’ve used:

Drawing on content from Teach Access (teachaccess.org), we use the framework of inclusive design focusing on disability as a mismatch between the needs of the individual and the design of the service, product, or environment. This thinking can often lead to more inclusive and innovative product designs that think less about what a person has difficulty doing (seeing, using their hands, speaking, etc.) and more about how an app/site/device can make a task easier (voice commands, artificial intelligence, Internet of things). We stress that accessibility requires creativity. Students learn about six categories of disability—cognitive/sensory/learning, hearing, mobility, vision, speech, and neural—and then consider other characteristics like age and situational/temporary/environmental limitations. Accessibility is considered with respect to relevant legislation, benefits for all users, driving creative solutions, and creating greater market opportunities.

Students learn about accessibility in JavaFX. JavaFX supports accessibility through the operating system. The controls can be read via a screen reader and are traversable using the keyboard, and there’s support for a high-contrast mode. Within Node, there are 4 properties that correspond to the most common cases for adding accessibility: accessibleRoleProperty, accessibleRoleDescriptionProperty, accessibleTextProperty, and accessibleHelpProperty. (See this site to find out more). As a class activity, we turn on VoiceOver or Narrator and demonstrate how an application is read.

Teaching A11y through Testing – Michael Ball, Gradescope

At Gradescope, I’ve led our accessibility work, training coworkers and working with university accessibility audits. In that role, I’ve thought a lot about how I would teach accessibility. Using a variety of tools helps to focus on the bigger picture. Instead of memorizing ARIA Standards, tests catch the error for you. Through using accessibility testing tools, we can

  • teach accessibility while teaching software engineering practices;
  • work accessibility testing, remediation, etc. into the software development cycle;
  • use industry-standard tools; and
  • develop familiarity with accessibility (which is a valuable job skill).

There is an important caveat. Automated testing does not guarantee an accessible experience and is not a substitute for testing with real users. And there are things that automated testing can’t tell us:

  • Does the experience make sense?
    • Do users tab through elements in a logical order?
    • Are the icons used for consistent meanings across pages?
    • Do form controls behave in the same way?
  • Cannot prevent “overusing” ARIA.
    • Too much extra markup is just as bad as not enough.
  • Cannot tell you when you need to use a more semantic element.
    • Tools do not understand the context of your page.

Automated testing runs a series of tests against your code or a live page, typically assessing WCAG standards. It ensures images have labels/alt text, ensures “clickable” elements have proper roles, checks color for proper contrast, and checks proper ordering of headings. These are relatively simple things that do add up! There are semi-automated tools that are bookmarklets, browser extensions, or web inspectors that audit a web page on demand, by a user clicking a button. There are also automated tools that run as a “background” task, such as part of a “continuous integration” or other automated test suites. If you already have a set of test cases, then adding accessibility testing is usually not too difficult.

Here is a list of some semi-automated tools that we use:

  • tota11y, a bookmarklet by KhanAcademy. With tota11y, you click to run the test and get a pop up in the lower left corner. It will give advice to fix problems (e.g. colors that would be appropriate for color contrast if existing ones aren’t);
  • Lighthouse is integrated into Chrome dev tools. Open the Developer Tools with (Control) or Command-Option-I and select the Audits Tab and you’ll be able to check accessibility.
  • ASLint; and
  • HTML CodeSniffer.

You can find more semi-automated tools here. A potential assignment involves using one of these tools to audit your project work and reporting findings and adjustments you can make. Because this is not automated you could repeat the process later in the project cycle. These tools could also be used to audit public sites.

For automated accessibility testing, axe-core, eslint-jsx-a11y, and accesslint.com are potential tools to use. Axe-core is a low-level library for testing HTML pages against WCAG standards maintained by Deque Labs. You can run a series of tests on every page load in development. There are versions that integrate with test suites directly. The eslint plugin is a code linter that audits React projects. Maintained by AirBnB and Facebook, it has very good documentation. There are variants for Vue and other frameworks. Linters can run in development or as part of an autograder. Accesslint is a GitHub-only plugin that runs on each pull request and creates a comment for new issues.

Find more resources on the A11y Project Resources page.

Accessibility + Information – Amy J. Ko, UW

I’m a professor in the Information School at the UW. I chair our undergraduate program (called Informatics). We teach over 500 students about how to design, develop, and deploy information systems that solve information problems. The degree program teaches about data, design, and development, covering topics like data science, databases and data modeling, information retrieval, web development, user experience design, privacy and security, and data ethics and policy. Accessibility is woven throughout our curriculum in intro, foundation, elective, and capstone courses.

Human beings create, find, and perceive information using media (speech, paper, computers, etc.). All media varies in the abilities it requires. Spoken communication requires hearing. Paper and websites require sight and fine motor control. Everyone should be able to create, find, and perceive information. Therefore, all media should be accessible via all abilities.

In INFO 200 Foundations of Information, one lecture covers definitions of accessibility, the history of accessibility, access technologies, and universal design. Students learn to use a screen reader and identify accessibility defects by testing with a screen reader.

In INFO 340 Client-Side Development, one week of the course focuses on HTML. The course describes tags and attributes as content metadata that help software render content in different forms: browsers render light and screen readers render sound. Students identify missing metadata in HTML that cause either browsers or screen readers to render HTML incorrectly or ambiguously.

In INFO 350 Information Ethics + Policy, one lecture focuses on Section 504 of the Rehabilitation Act of 1973 and the Americans With Disabilities Act of 1990 that discusses the parts of the law that concern information, such as website accessibility, and deconstructs ethics of equitable access. Students engage in discussion of the tradeoff between equitable access and cost of creating universally accessible information systems.

INFO 360 HCI + Design Methods is a standard human-computer interaction course, but with more advanced accessibility topics since they’re covered elsewhere. There is one day on access technologies and one day on universal design. Students’ final projects involve designing and specifying an information system. The specification must include a detailed analysis of what abilities are required to use their design and who will not be served by it.

INFO 442 Cooperative Software Development is a software engineering course with a focus on human and collaborative aspects of coordinating a software team. There is a chapter on software architecture that discusses it from the perspective of usability and accessibility supporting architectural patterns. In a project, students deploy two versions of a mobile app or web app. Applications must be fully screen readable using screen readers built into major operating systems.

INFO 463 Input and Interaction is a course on input and output in user interfaces, including advanced topics on accessible computing:

  • Motor-physical disabilities and how they affect pointing
  • Vision impairments and how they affect perception
  • User interface toolkit support for accessibility

One of three projects from which students can select is inventing a new interaction technique that improves accessibility for people with a particular disability (e.g., motor tremors).

INFO 490 Capstone is an open-ended six-month project with optional industry sponsors. Because all students have had exposure to accessibility, about 10% of teams each year focus on accessibility. Common sponsors of accessibility projects include Microsoft, Adobe, and the Gates Foundation.

Accessibility isn’t niche. In a degree about information, accessibility is central. Therefore, accessibility is central to any computing course that is about creating or accessing information. In a CS curriculum many courses are about creating or accessing information, including databases, operating systems, human-computer interface, software engineering, language technologies, artificial intelligence, and programming languages. These are all places where information about accessibility could be included.