| | (800) The Importance of Systems Survey and Analysis in Helping Identify Risks and Prioritize Efforts Beth Crutchfield VP, Policy & Program Services Sam Joehl Principal Technical Consultant

Agenda Overview of Systems Survey and Analysis Information Collection Process Survey Conduction Process Data Analysis Process Q&A

| | (800) Overview of Systems Survey and Analysis

What is a Systems Survey and Analysis: –An inventory of an organization’s digital systems What is included within the Systems Survey and Analysis: –A list of all systems categorized and prioritized by risk –A list of risk factors for each system –A model for building a compliance or maturity roadmap

| | (800) Information Collection Process

What Information is Needed? Name of the system Who uses the system? (What roles leverage the system?) What platform is the system built on? −What is the level of accessibility support for each platform? −What native or third-party assistive technologies are available? −What risks are inherent to the platforms used?

What Technologies Are Used? What technologies are used to develop the platform? –Level of accessibility support for the technology -Any inherent risks -How must the technology be implemented to be accessible and how difficult is this? -Embedded technologies used (plugins, embedded web views, etc.) and any associated risks? -3 rd party technologies or frameworks implemented and any associated risks?

System Traffic and Use Site Traffic Frequency by which system is accessed by individuals with disabilities? Is the system part of a core path or task that is commonly performed or accessed? Is the system part of a core path that is needed to access other systems such as a login screen, configuration settings or network or Wi-Fi access?

Legal Risks and Exceptions Are there legal risks associated with the system? Complaint’s driven risks Mandatory legal obligations Does any portion of the system qualify for an exception to the law, the org’s policy, etc.? –Amount of revenue generated by the system –What accessibility measures have been implemented –Potential accessibility pitfalls or risks –Contact point for the system

| | (800) Survey Conduction Process

The Survey Conduction Process Create a list of all digital assets that accessibility is applicable to Establish a contact point for each system –Send them relevant questions to collect the data needed If possible, schedule a walkthrough of each system –Collect additional information, observations and surface evaluation (keyboard access, color contrast, etc.)

| | (800) Data Analysis Process

Data Analysis Process – Identify Categories Identify categories or risk levels that each system will be placed into: –High – legal, financial or social danger to the org –Medium – some risk exists but the potential damage to the org is lower –Low – the system is not likely to place the org in jeopardy

Data Analysis Process – Determine Criteria Determine the criteria for classifying each system: –Algorithmic: Assign weights to each risk factor –Legal: Classify based on the legal ramifications –Traffic and use: How discoverable is the risk? –Technical: How difficult is overcoming any technical barriers? –What criteria would elevate a system to a higher risk category? (receipt of complaint, inclusion in a bid, etc.)

Data Analysis Process – Classify Systems Classify each system –High: high legal risk, high traffic, public and user-facing, significant technology or accessibility barriers –Medium: fewer users, restricted to specific roles, less legal visibility and obligations, mitigations and workarounds for technology and accessibility issues –Low: not much legal or regulatory coverage (such as qualifying exceptions), low visibility, solely used for maintenance or setup tasks, restricted to use by a few users or not many users with disabilities, deprecated and legacy systems, systems for which fully accessible alternatives are available

| | (800) Client Case Study

Case Study – High Risk TechnologyUniversityDescriptionRisks Insert nameInsert Name Proprietary platform for Online texts and materials. The product is available as web-based and mobile app (iOS and Android) interfaces. Implementation of “spanification” within the application allows for functional accessibility solutions. All books have audio book alternatives and the team avoids the use of Flash. JWPlayer is used for multimedia (videos) and regarded in the accessibility community as an accessible video player. POCs: (Insert names) Front-end developers are cognizant of accessibility but not familiar with standards or best practice approaches to ensuring accessibility. Although the Note feature is not commonly used, the Highlight feature is. Annotations and highlights are explained in print format provide a means of conveying the information without relying solely on color. However, there are no tooltips (textual alternatives) for the highlight buttons. This is a disadvantage for color blind students. Unfortunately, there is no keyboard equivalent to implement the Note and Highlight features currently in the application. Developers use of "spanification" allow for the functional highlighting with the mouse. Since developers are tracking the id attributes for all elements within the system, recommending and implementing functional accessibility solutions is feasible. For example, the developers have the ability to provide alternatives to the inline annotation objects currently implemented via CSS background images. Developers would be able to provide off-screen positioned text as a solution for identifying when highlights or notes begin within relation to the content. Each word is a separate object within the iOS app resulting in a disjointed reading experience for users of VoiceOver, the built-in iOS screen reader. Each word is highlighted as the user swipes left and right. Recommended providing a mode that provides a reading experience for VoiceOver users comparable to that provided within the iBooks app. Recommended harmonizing with ePub3 standards which incorporate the DAISY standard for digital talking books allowing for granular control over navigation and review of a publication. When a user searches for a word or phrase, the search result is highlighted within the text with color. A non-sighted or color-blind user will be at a disadvantage. The “spanification” methods implemented could provide for a functional solution by setting focus to the any particular result and adding and removing features within the Document Object Model (DOM). No formal audits or assistive technology testing has occurred. It was discovered that the system implements Asynchronous JavaScript and XML (AJAX) that should be tested to confirm that assistive technologies track dynamically displayed content accurately. The top navigation links is in located within the HTML source correctly. However, dynamically displayed menus are not in-line with the parent menu items (developed as HTML links). In addition the programmatic focus does not move to these menu items when the parent link is activated. The risk is that keyboard-only users and users of assistive technologies may not be able to access the menu items or become aware that they are present within the application.

Case Study – Medium Risk TechnologyUniversityDescriptionRisks Insert Name Tool used for tests and quizzes. POCs: (Insert Names) Radio buttons and checkboxes for multiple choice questions are explicitly labeled which meets WCAG success criteria 3.3.2: “Labels or Instructions” and 2.4.6: “Headings and Labels."However the questions that form groups of radio buttons and checkboxes are not structured with HTML and elements which violates WCAG 2.0 Success Criteria 1.3.1: “Info and Relationships” preventing a nonvisual method of determining the relationship between the question and associated responses. While not a barrier to access, some screen reader users may suppose the question to be associated or labeled to the explicitly labeled answers within a question group. The risk is medium as we have only viewed samples of quizzes that contain multiple choice values of radio buttons and checkboxes. The risk may increase if there are quizzes that allow for dragging and dropping or essay style. Further manual tests and examples of quizzes must be tested further to ensure support with assistive technologies and with the keyboard.

Case Study – Low Risk TechnologyUniversityDescriptionRisks Insert Name The Journal is a convenient feature that allows students to engage in private written dialogue with their instructors. Once students share their Journal work with instructors, instructors can provide direct feedback. Currently the Journal provides a private area that only the instructor can view. POCs: (Insert Names) Instructors must ensure that color is not a sole means of conveying information to students when a student is reviewing comments from the professor. The student facing application contains a rich text editor that often limits a keyboard user the means of formatting the information the same as a mouse user. No information available regarding any keyboard shortcuts or documentation as “Job Aids” for users of these controls.

Questions?

Thank You Contact Us Beth Crutchfield VP, Policy and Program Services Sam Joehl Principal Technical Consultant, Accessibility Services SSB Contact Information (800) Follow linkedin.com/company/ SSB-BART-Group facebook.com/ SSBBARTGroup SSBBARTGroup.com/blog

| (800) | About SSB BART Group Unmatched Experience Focus on Accessibility Solutions That Manage Risk Real-World Strategy Organizational Strength and Continuity Dynamic, Forward-Thinking Intelligence Fourteen hundred organizations (1445) Fifteen hundred individual accessibility best practices (1595) Twenty-two core technology platforms (22) Fifty-five thousand audits (55,930) One hundred fifty million accessibility violations (152,351,725) Three hundred sixty-six thousand human validated accessibility violations (366,096)