MisFits QA Accessibility Testing MeetUp

Accessibility Testing Discussion Notes

Event: Misfits of QA MeetUp, Toronto, Ontario
Host: Anastasia Powell, Head of Quality Assurance at Mercatus Technologies Inc.
Topic: Accessibility Testing – What do we know?
Speaker: David Best, Accessibility Information Technology Specialist
Date: June 21, 6:30pm
Location:
MisFits QA web page

Definition Of Common Terms

What is Accessibility?

Web Accessibility is the deficit gap between the Disability of the user and the System capabilities. The goal is to bridge the Accessibility Gap, through Universal Design, that will create the best possible interoperability of System components to achieve the desired User experience.

  • Productivity that enables employees to be productive and satisfied.
  • Inclusion that integrates people, products, and services.
  • Communications that informs people, builds knowledge, and creates confidence.
  • WebAIM: Introduction to Web Accessibility

What is Usability?

Usability is the ease of use and learnability of a human-made object, and includes methods of measuring the user experience. That is, Usability describes the quality of the user experience across the entire website.

  • Assistive and adaptive tools designed for a specific purpose (walker, wheelchair, screen reader, and braille display).
  • Mainstream universal design products (appliances, ATMs, smart devices, and websites).

What is Interoperability of system components?

What is a Disability?

People with disabilities access and navigate the Web in different ways, depending on their individual needs and preferences. Sometimes people configure standard software and hardware according to their needs, and sometimes people use specialized software or hardware that help them perform certain tasks.

What is Accessibility for Ontarians with Disabilities Act (AODA)?

Recognizing the history of discrimination against persons with disabilities, the province of Ontario has taken a global leadership role in setting legislative Accessibility Standards for an inclusive society. The purpose of the AODA is to benefit all Ontarians by developing, implementing and enforcing accessibility standards in order to achieve accessibility for Ontarians with disabilities with respect to goods, services, facilities, accommodation, employment, buildings, structures and premises on or before January 1, 2025.

What is Web Content Accessibility Guidelines (WCAG)?

Web Content Accessibility Guidelines (WCAG) covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities. Following these guidelines will also often make your Web content more usable to users in general. WCAG success criteria are written as testable statements that are not technology-specific.

What is Accessible Rich Internet Applications (ARIA)?

Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with disabilities. ARIA specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications.

  • Roles to describe the type of widget presented (such as menu, tree item, slider, and progress meter).
  • Roles to describe the structure of the Web page (such as headings, regions, tables, and grids).
  • Properties to describe the state widgets are in (such as checked for a check box, or has popup for a menu).
  • Properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy update (such as critical updates presented in an alert dialog box, and incidental updates occurring within the page).
  • Properties for drag-and-drop that describe drag sources and drop targets.
  • A way to provide keyboard navigation for the Web objects and events.
  • Resource: Accessible Rich Internet Application (ARIA)

Evaluation And Reporting

What is functional testing?

The purpose of Functional testing is to ensure code is behaving as expected and website design is defect free.

  • Beta testing
  • Automated accessibility tools
  • Dynamic page rendering
  • operable functionality
  • native HTML5 parsing
  • ARIA widget properties

Some Automated Tool Scans

  • Images missing alt attributes.
  • Form fields missing explicit labels and/or titles.
  • No title on a web page.
  • No primary web page language.
  • Invalid Markup Parsing; elements have start and end tags, are nested according to their specifications, do not contain duplicate attributes, and IDs are unique.
  • Resource: Accessibility Evaluation Tools

What is usability Testing?

Usability Testing deals with user behaviour, and determines user experience.

  • User focus groups: Groups of test participants who have different needs, skills sets, browser configuration options, and assistive technologies.
  • User manual tests: Manual test must be done with keyboard only, screen readers, and other user agents.
  • Can users complete tasks and achieve their goals on the web application (effectiveness)?
  • How much effort and time do users require to complete the task (efficiency)?
  • Do users find the website easy to use and learn (satisfaction)?

What is accessibility evaluation reporting?

Web accessibility reporting must be integrated into the product life cycle strategy to enhance organizational skills and customer satisfaction.

Report Scope

  • Define evaluation tasks: Functional and/or Usability.
  • Define a baseline of web technologies: User agents and system platform used.
  • Define the standards and conformance guidelines: WCAG2.0 A, AA, AAA, or some other standard.
  • Define Accessibility law requirements: Ontario AODA standards, U.S. Section508, or others.
  • Define testing methodology: Tools, expertese, and/or user groups.
  • Define test procedures: Persona scripts, specific web pages, specific functions, or user focused.
  • Define the report style: Document, videos, and/or training.
  • Define the delivery process: Executive presentation, management conference, and/or developer workshop.

Report Evaluation Severity

  • Critical:
    Must fix to allow even the most basic use of the application. User with a disability cannot complete a task, and no alternate means is provided to complete
    that task. The issue is a violation of the Web Accessibility Checklist.
  • High:
    Must fix in order to meet accessibility standards and allow full use of the system. User with a disability will likely not be able to easily complete a
    task, and no alternate means is provided to complete the task. The issue is a violation of the Web Accessibility Checklist.
  • Medium:
    Should fix to allow productive, accessible use of the application. User with a disability will likely be able to complete a task, but the issue prevents
    the user from completing the task efficiently. The issue may or may not be a violation of the Web Accessibility Checklist.
  • Low:
    User with a disability will be able to complete a task, but the issue may cause confusion to the user, and should be resolved. The issue may not be a violation of the Web Accessibility Checklist. These may be functionality bugs that may effect all users, and should be corrected in any case.

Identify the interoperability user challenge

  • The developer did not markup/code the web page properly, or
  • The browser or media player isn’t handling the markup properly, or
  • The user’s Assistive Technology (AT) isn’t handling the markup properly, or
  • The user doesn’t know how to use the browser, media player, and user agent keyboard access features, or
  • The page is poorly designed and it is a general usability problem for all users, including those without disabilities.

What are the primary screen reader success criterias?

The following is not a complete list of WCAG success criteria, and you should refer to the W3C/WAI web site for more details on using the WCAG criteria. If time permits, a live hands-on demonstration of accessibility evaluation of real web sites can be performed.

  • WCAG1.1.1: Alternative Image text
    All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. Such as, pictures and charts have alternative
    text descriptions.
  • WCAG1.3.1: Content relationships
    The web page should be divided into perceivable block areas, which contain semantically associated information called Regions. Each region can be divided
    into logical subregions as needed. For users with cognitive and learning disabilities the landmark information could be used to expand and collapse these
    regions of your page to aid in simplifying the user experience by allowing the user to manage the amount of information processed at any one time.
  • WCAG1.4.1: Use of colour
    Colour alone is not used to convey hierarchy, functionality and content. For people with visual disabilities such as colour blindness, relying solely on
    colour to convey hierarchy, functionality and content means they will not be able to use the product.?Using more than three colours may make content understanding
    difficult. sometimes, for specific cases, more than three colours can be used, but this is not a fixed rule.
  • WCAG1.4.3: Sufficient background and text contrast
    Foreground elements are easily distinguished from the background. Clear distinction facilitates navigation, brings more attention to buttons and increases usability.
  • WCAG1.4.8: Visual presentation
    There should be clear indicators as to what is content and what are controls. These indicators can be size, colours, font etc. By using different styles or families, user will not be confused and will easily identify what can be interacted with.
  • WCAG2.1.1: Keyboard Access
    The intent of this Success Criterion is to ensure that, wherever possible, content can be operated through a keyboard or keyboard interface (so an alternate keyboard can be used). When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input software, sip-and-puff software, on-screen keyboards, scanning software and a variety of assistive technologies and alternate keyboards.
  • WCAG2.4.1: Skip content
    People who use magnifiers to view a web site find skip links useful. Often a person using a magnifier will only see a small part of the screen. Often it is not obvious where the content is from this small part of the screen. This is in contrast to a sighted user’s ability to ignore the repeated material either by focusing on the center of the screen (where main content usually appears) or a mouse user’s ability to select a link with a single mouse click rather than encountering every link or form control that comes before the item they want.
  • WCAG2.4.2: Page Title
    Every web page should have its own, unique Title element that identifies the page content and its website orientation.
  • WCAG2.4.4: Link purpose
    Ensure Link Text labels Make Sense. The intent of this Success Criterion is to help users understand the purpose of each link so they can decide whether they want to follow the link. Whenever possible, provide link text that identifies the purpose of the link without needing additional context. Assistive technology has the ability to provide users with a list of links that are on the Web page. Link text that is as meaningful as possible will aid users who want to choose from this list of links. Meaningful link text also helps those who wish to tab from link to link. Meaningful links help users choose which links to follow without requiring complicated strategies to understand the page.
  • WCAG2.4.5: Breadcrumb
    Breadcrumbs are an additional navigation tool that assists both the general public and people with disabilities to navigate through a large or complex site. It is especially important where other navigation mechanisms, such as the Back button, have been broken. Breadcrumbs should provide the hierarchical position not the chronological pathway in the site. For instance, even if a user came to a particular part of the site through inline links, the breadcrumbs should provide the navigational pathway to that page.
  • WCAG2.4.6: Logical Heading hierarchy
    It is important that headings are nested properly in order to convey the structure and hierarchy of the page. It is important not to skip heading levels (Example, a H4 should not follow an H2). Screen reader users scan a web page using a variety of features, such as links, form controls and headings. Most screen readers can pull out the headings, and present them to the screen reader user in hierarchical order. This can provide a great amount of information to users and help them navigate through the page effectively.
  • WCAG2.4.7: Visual focus
    Make Sure Links are Recognizable. The purpose of this success criterion is to help a person know which element has the keyboard focus.
  • WCAG3.1.1: Page language
    Both assistive technologies and conventional user agents can render text more accurately when the language of the Web page is identified. Screen readers can load the correct pronunciation rules. Visual browsers can display characters and scripts correctly. Media players can show captions correctly. As a result, users with disabilities will be better able to understand the content.
  • WCAG3.2.3: Consistent navigation
    The way user navigates through the website directly influences whether they can achieve their goals irrespective of the page they are on. That is, navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated.
  • WCAG3.3.1: Easy error recovery
    Users may perform actions that lead them to undesired results. Allowing the users to go back and given the opportunity to try again will reduce frustration.
  • WCAG3.3.2: Form fields
    Ensure Forms have explicit labels and/or titles. Instructions or labels that identify the controls and data fields in a form are clear so that users know what input data is expected. Instructions or labels may also specify data formats for fields, like dates and times.
  • WCAG4.1.1: Invalid HTML Parsing
    HTML Elements have start and end tags, are nested according to their specifications, do not contain duplicate attributes, and element Ids are unique. The intent of this Success Criterion is to ensure that user agents, including assistive technologies, can accurately interpret and parse content. If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it.