{"id":87,"date":"2018-04-17T17:33:50","date_gmt":"2018-04-17T17:33:50","guid":{"rendered":"https:\/\/www.w3.org\/community\/silver\/?page_id=87"},"modified":"2018-04-25T16:33:06","modified_gmt":"2018-04-25T16:33:06","slug":"draft-final-report-of-silver","status":"publish","type":"page","link":"https:\/\/www.w3.org\/community\/silver\/draft-final-report-of-silver\/","title":{"rendered":"Draft &#8211; Report of Silver Design Sprint"},"content":{"rendered":"<p><a href=\"http:\/\/www.w3.org\/\"><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/www.w3.org\/Icons\/w3c_home\" alt=\"W3C\" width=\"72\" height=\"48\" \/><\/a><\/p>\n<h1 id=\"h.elyffbde7f6d\">Silver Design Sprint Report<\/h1>\n<h2 id=\"subtitle\">W3C Community Group Report 23 April 2018<\/h2>\n<dl>\n<dt>Latest version<\/dt>\n<dd><a href=\"https:\/\/www.w3.org\/community\/silver\/draft-final-report-of-silver\/\">https:\/\/www.w3.org\/community\/silver\/draft-final-report-of-silver\/<\/a><\/dd>\n<dt>Editor:<\/dt>\n<dd>Jeanne Spellman<\/dd>\n<\/dl>\n<p class=\"copyright\">Copyright \u00a9 2018 the Contributors to the Report Silver Design Sprint, published by the\u00a0<a href=\"https:\/\/www.w3.org\/community\/silver\/\">Silver Community Group<\/a>\u00a0under the\u00a0<a href=\"https:\/\/www.w3.org\/community\/about\/agreements\/cla\/\">W3C Community Contributor License Agreement (CLA)<\/a>. A human-readable\u00a0<a href=\"http:\/\/www.w3.org\/community\/about\/agreements\/cla-deed\/\">summary<\/a>\u00a0is available.<\/p>\n<h2 id=\"h.acsmbc1bt7wr\">Abstract<\/h2>\n<p>The Report of the CSUN Design Sprint is intended for people interested in the W3C accessibility guidelines standard development, particularly the preliminary work being done to design the successor to WCAG 2. The Silver Design Sprint of March 19 &amp; 20 2018 held at San Diego State University addresses problem statements identified by the year of research completed by the Silver Task Force, the Silver Community Group, and their research partners. \u00a0This summary of the work done by the Design Sprint participants is organized into sections with a link to each section:<\/p>\n<ul>\n<li><a href=\"#h.xj3bu3gonrsl\" target=\"_blank\" rel=\"nofollow\">Silver Design Sprint Overview<\/a><\/li>\n<li><a href=\"#h.gk74muhw71r3\" target=\"_blank\" rel=\"nofollow\">Problem Statements<\/a>\u00a0that the Design Sprint addressed<\/li>\n<li><a href=\"#h.z42t1yt3iwlx\" target=\"_blank\" rel=\"nofollow\">Design Sprint Results<\/a>\u00a0&#8211; Ideas and prototypes generated by the participants sorted by Problem Statement<\/li>\n<li><a href=\"#h.m0z7skqofjzn\" target=\"_blank\" rel=\"nofollow\">Suggestions<\/a> for direction of the Silver project.<\/li>\n<li><a href=\"#h.rzft8p6vp0fd\" target=\"_blank\" rel=\"nofollow\">Next Steps<\/a>\u00a0Invitation for public participation in the prototyping process<\/li>\n<li><a href=\"#h.a9u4z1wwr2f\" target=\"_blank\" rel=\"nofollow\">Appendix <\/a>&#8211; links to the presentation videos, &#8220;How Might We&#8230;&#8221; ideas, links to all of the notes that could be transcribed, and a link to all the raw data.<\/li>\n<\/ul>\n<p>This is probably a TLDR (too long, don\u2019t read) paper for most people. \u00a0Please feel free to go to the <a href=\"#h.m0z7skqofjzn\" target=\"_blank\" rel=\"nofollow\">Suggestions<\/a> section for the essential information.<\/p>\n<p>It is important to note that these are only recommendations. \u00a0The Silver project participants will be testing and evaluating these recommendations as they develop prototypes. \u00a0They may be changed or removed from the final prototype.<\/p>\n<p>Comments are welcome by email to: <a href=\"mailto:public-silver@w3.org\" target=\"_blank\" rel=\"nofollow\">public-silver@w3.org<\/a><\/p>\n<h2 id=\"sotd\">Status of this document<\/h2>\n<p>This report was published by the <a href=\"http:\/\/www.w3.org\/community\/silver\/\">Silver Community Group<\/a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href=\"http:\/\/www.w3.org\/community\/about\/agreements\/cla\/\">W3C Community Contributor License Agreement (CLA)<\/a> there is a limited opt-out and other conditions apply. Learn more about <a href=\"http:\/\/www.w3.org\/community\/\">W3C Community and Business Groups<\/a>.<\/p>\n<h2 id=\"h.ngjzlu6u8ncd\">The Silver Project<\/h2>\n<p>The <a href=\"https:\/\/www.w3.org\/WAI\/GL\/task-forces\/silver\/\">Silver Task Force<\/a>\u00a0is part of the <a href=\"https:\/\/www.w3.org\/WAI\/GL\/\">Accessibility Guidelines Working Group<\/a> of the W3C. The Silver Task Force and the <a href=\"https:\/\/www.w3.org\/community\/silver\/\">W3C Silver Community Group<\/a>\u00a0are performing the preliminary work for the successor to the Web Content Accessibility Guidelines (WCAG). The guidelines will have a new name that reflects the anticipated broader scope beyond web content. The name Silver comes from the acronym for Accessibility Guidelines, AG. \u00a0Ag is the chemical symbol for the element silver.<\/p>\n<p>Silver is currently in the Ideation and Experimentation (prototyping and user testing) phase of the original <a href=\"https:\/\/www.w3.org\/WAI\/GL\/task-forces\/silver\/wiki\/Design_Plan_for_Silver\">Design Plan for Silver<\/a>. The Silver Task Force is partnering with researchers who are studying different aspects of the current WCAG. Research related to the structure of Silver was completed by March 2018. A <a href=\"https:\/\/www.google.com\/url?q=https:\/\/docs.google.com\/presentation\/d\/1POs7orJ4ALB0bq5_vyo4v8RxDcr-5ctwD1noVgpXuJc\/edit?usp%3Dsharing&amp;sa=D&amp;ust=1523985406052000\" target=\"_blank\" rel=\"nofollow\">summary of the structure-related research<\/a>\u00a0is publicly available. Many of the individual papers are also public and are linked from the summary. Research related to Silver content will be on-going.<\/p>\n<p>Participation in the Silver Task Force is open to the public. Interested people can join the <a href=\"https:\/\/www.w3.org\/community\/silver\/\">W3C Silver Community Group<\/a>\u00a0to be placed on the mailing list and join conference calls.<\/p>\n<h2 id=\"h.xj3bu3gonrsl\">Silver Design Sprint<\/h2>\n<p>The Silver Design Sprint held prior to the CSUN 2018 AT Conference, was the result of a year of research into the structural improvements for the existing W3C Accessibility Guidelines indicated by the research projects. \u00a0The <a href=\"https:\/\/www.google.com\/url?q=https:\/\/docs.google.com\/presentation\/d\/1POs7orJ4ALB0bq5_vyo4v8RxDcr-5ctwD1noVgpXuJc\/edit?usp%3Dsharing&amp;sa=D&amp;ust=1523985406053000\" target=\"_blank\" rel=\"nofollow\">summary of the research<\/a>\u00a0completed to date with links to the individual reports is publicly available.<\/p>\n<p>The Silver group brainstormed categories of roles within digital accessibility that they wanted to invite and individually invited participants who provided expertise in each role, and overall created a balanced and varied group of perspectives. \u00a0About 30% of the experts invited also have a disability (for privacy reasons, we did not track exact statistics). Inclusion of experts that also have a disability is an essential part of the success of the Silver project.<\/p>\n<ul>\n<li>Accessibility influencers<\/li>\n<li>Information architects<\/li>\n<li>UX professionals<\/li>\n<li>Developers (e.g., Web content, Document, Authoring tool, User Agent, Assistive Technology)<\/li>\n<li>Legal specialists<\/li>\n<li>Policy specialists<\/li>\n<li>W3C Process experts<\/li>\n<\/ul>\n<p>27 experts participated in the Design Sprint, which was hosted by San Diego State University and supported by donations from the University of Illinois Urbana-Champaign Libraries and Google. \u00a0The Design Sprint was moderated by Camron Shimy of Google, who is an expert in leading software design sprints using agile techniques.<\/p>\n<p><a href=\"https:\/\/www.w3.org\/WAI\/GL\/task-forces\/silver\/wiki\/Design_Sprint_Participants\">Design Sprint Participants<\/a><\/p>\n<p>The Design Sprint process began with a presentation of the research results organized by problem statement. \u00a0Participants were asked to create questions starting \u201cHow Might We\u2026\u201d as they heard the research results. \u00a0The participants worked in groups of 4-5 to decide on problem statements they wished to work on, brainstorm many solutions and start narrowing down solutions. \u00a0The groups then developed a prototype (usually paper) and user tested it with others outside the group, and refined the prototype based on feedback.<\/p>\n<h2 id=\"h.gk74muhw71r3\">Problem Statements<\/h2>\n<p>This research was used to develop 11 problem statements that needed to be solved for Silver. \u00a0 The detailed <a href=\"https:\/\/www.w3.org\/WAI\/GL\/task-forces\/silver\/wiki\/Problem_Statements\">problem statements<\/a>\u00a0include the specific problem, the result of the problem, the situation and priority, and the opportunity presented by the problem. \u00a0The problem statement were organized into three main areas: \u00a0Usability, Conformance, Maintenance.<\/p>\n<h3 id=\"h.6l8yczeelvon\">Usability<\/h3>\n<ul>\n<li>Too Difficult to Read\u00a0and translate.<\/li>\n<li>Difficult to get started\u00a0 for beginners.<\/li>\n<li>Ambiguity in interpreting the success criteria. Different accessibility experts will interpret the guidelines differently.<\/li>\n<li>Persuading Others\u00a0to follow WCAG is difficult mostly because of the perception that Accessibility is something added at the end of the development process and is costly.<\/li>\n<\/ul>\n<h3 id=\"h.n2wcg0gauz5x\">Conformance Model<\/h3>\n<ul>\n<li>Constraints on What is Strictly Testable provides an obstacle to including guidance that meets the needs of people with disabilities, but is not conducive to a pass\/fail test.<\/li>\n<li>Human Testable\u00a0(related to Ambiguity) also relates to differences in knowledge and priorities of different testers achieve different results.<\/li>\n<li>Accessibility Supported is a conformance requirement of WCAG 2 \u00a0that is poorly understood and incompletely implemented<\/li>\n<li>Evolving Technology of the rapidly changing web must constantly be evaluated against the capabilities of assistive technology and evolving assistive technology must be evaluated against the backward compatibility of existing web sites. .<\/li>\n<\/ul>\n<h3 id=\"h.wyfbilfx9roa\">Maintenance<\/h3>\n<ul>\n<li>Flexibility to provide more easily discovered, more helpful information that can be updated as technology advances.<\/li>\n<li>Scaling the accessibility guidance so it can be updated \u00a0to include new and changing technology<\/li>\n<li>Governance of the accessibility standards has not kept pace with changing processes of standard development.<\/li>\n<\/ul>\n<p>For a more complete discussion of the Problem Statements, see the <a href=\"https:\/\/www.w3.org\/WAI\/GL\/task-forces\/silver\/wiki\/Problem_Statements\">Silver Problem Statements<\/a>\u00a0paper.<\/p>\n<h2 id=\"h.z42t1yt3iwlx\">Design Sprint Results by Problem Statement<\/h2>\n<p>It is important to note that most of the solutions proposed or prototyped combine many aspects of the Problem Statements. \u00a0The prototypes developed by the small groups are organized in this report by the main problem statement they wanted to address. \u00a0There was uneven coverage of the problem statements, so some statements still need prototype work. \u00a0The Design Sprint generated 100s of post-it notes with brainstorming ideas which are captured under the section \u201cHow Might We\u201d ideas.<\/p>\n<h3 id=\"h.tgrhiscj0po2\">Too difficult to read<\/h3>\n<ol start=\"1\">\n<li>Every group proposed a solution that included writing Silver in simple language that was easy to understand and translate.<\/li>\n<li>\u201cPlain language\u201d already has definitions related to secondary education level published by other standards groups like ISO, whereas \u201csimple language\u201d may not be (as) constrained by other \u00a0definitions, and may better describe the intent.<\/li>\n<li><strong>It is difficult to write success criteria that have enough data and information to make it through the review process.<\/strong><\/li>\n<li>We need to move from conformance to usability; guidelines as written drive the wrong behavior because people are addressing accessibility at the end of the development process.<\/li>\n<li>Develop a framework to write success criteria that provides a consistent structure and helps people provide sufficient data and information.<\/li>\n<li>Create check points at each phase of the development process to make sure that accessibility is being systematically addressed throughout.<\/li>\n<li>Create entry points by organizational role (e.g developer, designer, procurement, AT developer, etc) \u00a0to provide a quick way to filter the Silver guidance to essential information for that role, with links to additional information. <a href=\"https:\/\/www.google.com\/url?q=https:\/\/drive.google.com\/open?id%3D1Opd5uA0wn9ACOc9nrmCq4Vrv3x-WCtrp&amp;sa=D&amp;ust=1523985406058000\" target=\"_blank\" rel=\"nofollow\">Roles for Silver<\/a>\u00a0prototype was based on the <a href=\"https:\/\/www.w3.org\/community\/silver\/stakeholder-job-stories\/\">Stakeholder Job Stories<\/a>.<\/li>\n<\/ol>\n<h3 id=\"h.oxps4hf7uvy5\">Difficult to get started<\/h3>\n<ol start=\"1\">\n<li>How do you layout content for understandability? \u00a0How would you layout the actual information in the spec? \u00a0The group recommended using the Mozilla Developers Network (MDN) as an inspiration for a useful format. &gt;\n<ol type=\"a\">\n<li>Each spec would have it\u2019s own web page and then each part of those pages would address the impact to the user:\n<ul>\n<li>how the user interacts with it<\/li>\n<li>code samples<\/li>\n<li>best practices and then<\/li>\n<li>the actual statement of the spec.<\/li>\n<\/ul>\n<\/li>\n<li>Each spec would have its own page, but would not necessarily be numbered &#8211; this way you could add to each page as its own separate entity and therefore would not have to be tied to everything else, waiting for updates that need to be done to keep pace with technology as it develops.<\/li>\n<\/ol>\n<\/li>\n<li>How do you actually find what you need (Discovery)?. The group decided to develop a way for someone to read through the entire spec if they wanted to do so \u2014 this would be important for people involved in standards work, policy etc., but for others we thought we needed to develop a faceted search feature that could be split into three different sections:\n<ol type=\"a\">\n<li>Allow the user to choose their role (e.g. designer, developer, project manager, etc.). Based on the role, information would be targeted to what that role needs to know<\/li>\n<li>After choosing the role, you could then narrow the information presented by choosing the problem you\u2019re trying to solve (e.g. keyboard navigation, labels, alt text, accessible media, etc.<\/li>\n<li>After choosing the problem to solve, you could again narrow the information presented by choosing the delivery platform (mobile, web app, etc.).<\/li>\n<li>Develop a Q&amp;A wizard that would ask questions to help people find what they need (e.g. do you have a team, what platform are you working on, what problem are you trying to solve, etc.). \u00a0This would have to be developed over time, but we thought that a Q&amp;A wizard to help people get started would be really helpful.<\/li>\n<li>Develop a design-pattern library &#8211; \u201cthese are the things you have to have in order for things to work with users.\u201d \u00a0We keep forgetting the user. \u00a0People have to remember what the user is trying to do. \u00a0Silver should include personas and relate back to those personas in each part of the spec.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<h3 id=\"h.gvj3dmr8bb5l\">Constraints on What is Strictly Testable<\/h3>\n<ol start=\"1\">\n<li>The group looked at how testers would go about assessing a web application using measurements along a gradient of accessibility as opposed to a strict pass\/fail result. The tool to put together a report of the assessment puts an emphasis on:\n<ol type=\"a\">\n<li>personas: users\u2019 needs come first<\/li>\n<li>task-based assessment, rather than component-based assessment. A properly marked up button doesn\u2019t help anything if the user can\u2019t complete the task at hand.<\/li>\n<li>Note: this also makes a good midpoint of grading between component\/tag assessment and full page \/ complete processes compliance in the WCAG conformance model.<\/li>\n<\/ol>\n<\/li>\n<li><a href=\"https:\/\/www.google.com\/url?q=https:\/\/docs.google.com\/document\/d\/1XDOmjQkMRqQ0XKiKYA-mDAuA40oHtaXNl1H0NXLcV80\/edit%23heading%3Dh.vl196l7b6q07&amp;sa=D&amp;ust=1523985406060000\" target=\"_blank\" rel=\"nofollow\">Prototype for task-based assessment<\/a><\/li>\n<\/ol>\n<h3 id=\"h.lx8xa22oal0u\">Human Testable<\/h3>\n<p>The group consensus agreed that if no two experts would reach the same conclusion for a manual accessibility audit, that fact isn\u2019t inherently a bad thing and should be embraced using a peer-review methodology.<\/p>\n<h3 id=\"h.gwxhfdjtjq9f\">Accessibility Supported<\/h3>\n<p>There are different approaches to accessibility supported:<\/p>\n<ul>\n<li>Helping the engineering community understand which assistive technology support the code they are writing. WCAG 2.0 planned a database of support for features across AT and languages, but it never was done. \u00a0Resources needed to create and maintain a database were too daunting.<\/li>\n<li>Helping the assistive technology developers understand what is needed to support Silver. \u00a0The example of PC Talk screen reader in Japan does not support ARIA (and only recently got support for headings) because the PCTalk developers don\u2019t speak English and the spec is very difficult to translate. Create test files for AT developers to use. Test results can be public. \u00a0There was discussion whether AT providers can be held responsible for their support of Silver.<\/li>\n<li>Helping the browser developers understand what is needed to support people with disabilities who do not use assistive technology and people with disabilities who are poorly served by standard assistive technologies.\u00a0 There are features that content authors struggle to provide (for example, font size, spacing, color, enlarged printing, overflow controls that display text no matter what size, single column, and other features that improve the visual readability of rendered text) that are best provided by browsers.<\/li>\n<li>Determining when an assistive technology provides real accessibility support. \u00a0For example, screen magnification does not provide support for reading, but is held out as accessibility support.<\/li>\n<\/ul>\n<p>The group consensus was to remove author responsibility for accessibility supported and create guidance for assistive technology developers and browser developers that would provide information that would help design and prioritize implementation of features in their products that would support Silver. Several people argued strongly for requirements for assistive technology and browser requirements.<\/p>\n<p>The group decided to focus on Accessibility Supported for Assistive Technology developers for their first prototype, and included some of the ideas from Difficult to Read discussion. \u00a0The second version focused on User Agent (browser) developers, and the 3rd version focused on Procurement officers attempting to purchase accessible technology and determine if their mobile app met the accessibility guidance.<br \/>\nDetails of the <a href=\"https:\/\/www.google.com\/url?q=https:\/\/docs.google.com\/document\/d\/1TG1VsXu_oBPuDK08rcbTFhP25CT_oAsywtWPLkyjZGw\/edit%23heading%3Dh.lc4n1z6i23vr&amp;sa=D&amp;ust=1523985406062000\" target=\"_blank\" rel=\"nofollow\">accessibility supported prototype<\/a>\u00a0with links to photographs of the paper mockups.<\/p>\n<h3 id=\"h.e9i2fj4pz9un\">Flexibility<\/h3>\n<p>A \u201cdatabase all the things\u201d approach may help all or at least many of the problems. It would be easier to search and locate content for new audiences \/ novices as well as experts and other stakeholders. By parsing content into smaller simpler units, it would be easier to onboard and likely easier to translate. By being based on a tagged structure, it would be easier to identify related criteria as well as those with potential conflicts. It would also be easier to scale, govern and keep current if more of an open source model.<\/p>\n<h2 id=\"h.m0z7skqofjzn\">Suggestions from Silver Task Force and Community Group<\/h2>\n<p>These suggestions come from the members of the Silver Task Force and Community Group after discussing the results of the Design Sprint. The context of the suggestions is specific to the Design Sprint and will intersect with other needs of the project. Therefore, not all suggestions will necessarily be implemented as stated, but provide an important base of input to future planning.<\/p>\n<h3 id=\"h.bta2r07edzlm\">Usability<\/h3>\n<ol>\n<li>Take existing WCAG 2.1 guidance and rewrite it in plain language using editors with simple language or plain language experience. \u00a0The existing success criteria may need to be updated, but most of WCAG 2.1 guidance is still valid. \u00a0It needs more clarity, ease of reading and ease of translation.<\/li>\n<li>Organize the data in small snippets that can be coded and categorized so they can be assembled dynamically to meet the needs of the person looking for information.<\/li>\n<li>Create a comprehensive view for W3C Technical Report purposes, and for those who need to view the total document.<\/li>\n<li>Create a solution that addresses the needs of people to find information by role, problem, by disability, and by platform. \u00a0How can people discover what they need to know?.<\/li>\n<li>Design a homepage that is oriented toward helping beginners that is separate from the W3C Technical Report. \u00a0Include shortcuts for expert users who know what they want (e.g a code sample for an accessible tab panel)<\/li>\n<\/ol>\n<h3 id=\"h.gi7bi47dn8do\">Conformance<\/h3>\n<ol start=\"6\">\n<li>Design a\u00a0conformance structure and style guides that shift emphasis from \u201ctestability\u201d to \u201cmeasureability\u201d so that guidance can be included that is not conducive to a pass\/fail test. \u00a0Pass\/ fail tests can be included, but they are not the only way to measure conformance.<\/li>\n<li>Develop scorecard or rubric measures for testing task accomplishment, instead of technical page conformance.<\/li>\n<li>Develop a point and ranking system that will allow more nuanced measurement of the content or product: e.g. a bronze, silver, gold, platinum rating where the bronze rating represents the minimal conformance (roughly equivalent to meeting WCAG 2 AA), and increasing ranks include inclusive design principles, task-based assessment, and usability testing.<\/li>\n<li>Include a definition and concept for \u201csubstantially meets\u201d so people are not excessively penalized for bugs that may not have a large impact on the experience of people with disabilities.<\/li>\n<li>Remove \u201caccessibility supported\u201d as an author responsibility and provide guidance to authoring tools, browsers and assistive technology developers of the expected behaviors of their products.<\/li>\n<li>Develop a more flexible method of claiming conformance that is better suited to accommodate dynamic or more regularly updated content.<\/li>\n<\/ol>\n<h3 id=\"h.7w70fawqdsra\">Maintenance<\/h3>\n<ol start=\"12\">\n<li>Develop a core of rarely-changing requirements (normative) with modules of platform oriented advice, examples, tests, and support materials that can be updated as technology changes.<\/li>\n<li>Develop a method for accessibility experts to contribute new content, such as design patterns, codes and tests, where the experts vote material up and down without waiting for working group approval.<\/li>\n<li>Change the working group process to include Community Group participation.<\/li>\n<li>Improve access to specification development tools (e.g. Github) so that people with disabilities can more easily participate in spec development, whether through new or modified tooling.\u00a0There are existing efforts that can be incorporated and improved on.<\/li>\n<li>Develop specification content a small amount of guidance at a time, and fully develop the content before including it in the spec. \u00a0Keep a public schedule when issues will be worked on, so the public can contribute in a timely manner.<\/li>\n<li>Keep a changelog of all changes to the spec so it is easy for reviewers to find the changes.<\/li>\n<\/ol>\n<h2 id=\"h.rzft8p6vp0fd\">Next Steps<\/h2>\n<p>All the problem statements (and other ideas) need prototypes for the group to evaluate. \u00a0The following problem statements need more detailed ideas and prototypes:<\/p>\n<ul>\n<li>Ambiguity<\/li>\n<li>Persuading Others<\/li>\n<li>Evolving Technologies<\/li>\n<li>Scaling<\/li>\n<li>Governance<\/li>\n<\/ul>\n<p>The Recommendations all need more design and development into working prototypes. \u00a0The Silver project participants invite you to share ideas and prototypes with us.<\/p>\n<p>Interested in helping contribute?\u00a0Join the <a href=\"https:\/\/www.w3.org\/community\/silver\/\">Silver Community Group<\/a>\u00a0and reach out to the Silver Task Force at <a href=\"mailto:public-silver@w3.org\" target=\"_blank\" rel=\"nofollow\">public-silver@w3.org<\/a><\/p>\n<hr \/>\n<h2 id=\"h.a9u4z1wwr2f\">Appendix: \u00a0Resources and Notes transcribed from Design Sprint<\/h2>\n<p>Each table did a presentation of their prototype which was captured on video (MOV files):<\/p>\n<ul>\n<li><a href=\"https:\/\/www.google.com\/url?q=https:\/\/drive.google.com\/open?id%3D1rkoE5j95T7NurrxrKRGhQIOzUah8RyR5&amp;sa=D&amp;ust=1523985406066000\" target=\"_blank\" rel=\"nofollow\">Table 1 Part 1<\/a>\u00a0and <a href=\"https:\/\/www.google.com\/url?q=https:\/\/drive.google.com\/file\/d\/1sWcjZDABAqlr5r5dczvEBJ1EmJrQz89P\/view?usp%3Dsharing&amp;sa=D&amp;ust=1523985406066000\" target=\"_blank\" rel=\"nofollow\">Part 2<\/a>\u00a0(How to create success criteria with a form for public input)<\/li>\n<li><a href=\"https:\/\/www.google.com\/url?q=https:\/\/drive.google.com\/open?id%3D1NKe9lx7edUA00uDhvDh6ZOJaHKARnfz0&amp;sa=D&amp;ust=1523985406066000\" target=\"_blank\" rel=\"nofollow\">Table 2<\/a>\u00a0 (Accessibility Supported and Difficult to Read)<\/li>\n<li><a href=\"https:\/\/www.google.com\/url?q=https:\/\/drive.google.com\/open?id%3D1MrCnAUGxndbw8Hb7jqK-JXbg3zhAr5W-&amp;sa=D&amp;ust=1523985406067000\" target=\"_blank\" rel=\"nofollow\">Table 3<\/a>\u00a0(How to make information easier to discover)<\/li>\n<li><a href=\"https:\/\/www.google.com\/url?q=https:\/\/drive.google.com\/open?id%3D1QN750Vq5ztYa2dit5E3Kr_nQhB-gc6YI&amp;sa=D&amp;ust=1523985406067000\" target=\"_blank\" rel=\"nofollow\">Table 4<\/a>\u00a0(How guidance about video accessibility could be displayed)<\/li>\n<li><a href=\"https:\/\/www.google.com\/url?q=https:\/\/drive.google.com\/open?id%3D1Frt_wduaxDHqUGBBhXBCi8mgGUzZI4Te&amp;sa=D&amp;ust=1523985406068000\" target=\"_blank\" rel=\"nofollow\">Table 5<\/a>\u00a0(How to measure the usability of content for people with disabilities)<\/li>\n<\/ul>\n<p>The notes from each table were captured \u00a0and transcribed. Each table has a folder with photographs of the paper notes and diagrams, and a transcript of the notes that could be typed up.<\/p>\n<p>The general folder where all the documents, photos and videos are stored is also publicly available. The \u00a0<a href=\"https:\/\/www.google.com\/url?q=https:\/\/drive.google.com\/drive\/folders\/1dx1Pp6RraQmx8BAZCHIugMLVW9HQilew?usp%3Dsharing&amp;sa=D&amp;ust=1523985406068000\" target=\"_blank\" rel=\"nofollow\">Raw results from the Design Sprint<\/a>\u00a0are public for archival purposes.<\/p>\n<h3 id=\"h.zi3snq9jcr56\">\u201cHow Might We\u201d (HMW) ideas<\/h3>\n<ul>\n<li>Redefine success<\/li>\n<li>Create tools to support inclusive design<\/li>\n<li>Give regulators something that will drive the right behaviors and outcomes<\/li>\n<li>Get CEOs to champion inclusive design<\/li>\n<li>Redefine the entire product life-cycle to produce more usable results<\/li>\n<li>Give developers a sense of \u201cdone\u201d<\/li>\n<li>Balance between regulators, devs and all users (testable vs usable)<\/li>\n<li>Decouple testable from conformance<\/li>\n<li>Get rid of \u201caccessible\u201d to be inclusive<\/li>\n<li>Define testability to be about user goals and needs<\/li>\n<li>Flexibility to Testability<\/li>\n<li>Write down your own testability statements &amp; claim accessibility<\/li>\n<li>Consume<\/li>\n<li>Personalization<\/li>\n<li>Look beyond language<\/li>\n<li>Simulate non-readers (3 VOTES)<\/li>\n<li>Further use plain language (1 VOTE)<\/li>\n<li>Speak to people in their own language (2 VOTES)<\/li>\n<li>Different approaches for different audiences<\/li>\n<li>Write a spec about guidance and scenarios for phases (4 VOTES)<\/li>\n<li>Motivate difference audiences Write guidelines for \u201cplanning\u201d<\/li>\n<li>Write guidelines for \u201cdesign\u201d<\/li>\n<li>Write guidelines for \u201ccoding\u201d<\/li>\n<li>Write guidelines for \u201cbuild and deploy\u201d<\/li>\n<li>Write guidelines for \u201ctesting\u201d<\/li>\n<li>Write guidelines for executives<\/li>\n<li>Write guidelines\/guidance for designers<\/li>\n<li>Write guidance for developers<\/li>\n<li>Write guidance for people who rely on AT?<\/li>\n<li>Write guidelines for browsers to incorporate personalization for non-readers<\/li>\n<li>Write guidance for guidelines writers?<\/li>\n<li>Create videos to help designers do more accessible design?<\/li>\n<li>Use humor to make ally more accessible, while being inclusive to other languages\/customs?<\/li>\n<li>High level goal and technique combos?<\/li>\n<li>Use guidelines to drive inclusive design &#8211; beyond accessible<\/li>\n<li>Redefine testability to be about usability<\/li>\n<li>Conform usability<\/li>\n<li>Select regions for their WCAG, not just states of translated language version<\/li>\n<li>Guide for project manager (ex)<\/li>\n<li>Select option for their role to read WCAG (head space)<\/li>\n<li>Simplify for non-readers<\/li>\n<li>Work with (bcds) who has WCAG knowledge to incorporate WCAG to existing regional system<\/li>\n<li>Use (diztioning) and summarization<\/li>\n<li>What is strictly testable<\/li>\n<li>What is accessibility supported<\/li>\n<li>How might we support users who do not use AT?<\/li>\n<li>How do we define when AT does provide accessibility support?<\/li>\n<li>How do we determine accessibility support for personalization?<\/li>\n<li>What role should WAI have with accessibility support?<\/li>\n<li>How do we go backward from WwD needs?<\/li>\n<li>Human Testable: How do we test?<\/li>\n<li>How do we remove the fear from irritation?<\/li>\n<li>How might we identify reservability? (couldn\u2019t read)<\/li>\n<li>How might we provide techniques and keep up with Tech?<\/li>\n<li>How can we provide a reading sequence for varying levels of technology understanding?<\/li>\n<li>How can we identify the problems of different user roles?<\/li>\n<li>How do we find experience editors?<\/li>\n<li>How do we reconcile technology with different technical capability?<\/li>\n<li>Carefully identify the necessary user stories and create a learning sequence for each role.<\/li>\n<li>For people who use specialized AT and mainstream tech. There must be a process for PwD to identify non-support. \u00a0Detail expectations for AT should be developed. \u00a0Drop Accessibility Support from Content.<\/li>\n<li>IMG-2043 is out of focus. \u00a0How do we keep the ?? so that ?? disabilities are ?? Accessibility support must include what a PwD can use content for the understood purpose. \u00a0I must generate support. \u00a0Into platforms \/ UA \/Hardware<\/li>\n<li>How should personal needs for users with disabilities be coordinated between content and user agents?<\/li>\n<li>How should we drop accessibility supported?<\/li>\n<li>How might users who do not use AT be given accessibility support<\/li>\n<li>How might accessibility support for personalization be built into user agents?<\/li>\n<li>How might basic Accessibility support features be built?<\/li>\n<li>Complex interactions of content \/ browsers \/ AT must be resolved.<\/li>\n<li>Wayne\u2019s paper on Accessibility Support (IMG_2048 and 2049)<\/li>\n<li>Every requirement should be tied to (and easy to understand by) the role of the People accountable for it and the Needs of people who depend on it. \u00a0All people should be able to ENTER thru their NEEDS and responsibilities.<\/li>\n<li>HOW prioritize without giving disabled people Less<\/li>\n<li>HMW (re: difficult to read) have standards that reflect the end result of a11y &#8212; i.e. are inclusive in design.<\/li>\n<li>HMW have layers of guidance by role<\/li>\n<li>HMW Split out technology from Guidance? Core principles.<\/li>\n<li>HMW Recruit editors to translate existing guidance to plain language<\/li>\n<li>HMW give expectations and instructions<\/li>\n<li>HMW create test files for assistive tech<\/li>\n<li>Strictly Testable\n<ul>\n<li>User centered spec<\/li>\n<li>Fuzzy variable spectrum of PwD failure<\/li>\n<li>Personalization that isn\u2019t useless to developers<\/li>\n<li>If it can\u2019t be tested, it is useless to developers<\/li>\n<\/ul>\n<\/li>\n<li>HMW get buy in from other standards?<\/li>\n<li>HMW create a forum for exchanging information about new technology?<\/li>\n<li>HMW get early feedback from PWD for emerging technology?<\/li>\n<li>HMW get all PWD paid for money to do testing?<\/li>\n<li>HMW make AT ready to accept new technologies?<\/li>\n<li>HMW make ourselves aware of new technologies?<\/li>\n<li>HMW integrate a11y from the beginning?<\/li>\n<li>HMW increase empathy?<\/li>\n<li>HMW make accessible technology aspirational\/\u201dsexy\u201d?<\/li>\n<li>HMW get people to understand the flags\/ramifications of accessibility?<\/li>\n<li>HMW define success criteria more as a UX instead of a tech solution?<\/li>\n<li>HMW decide a process for creating SC for a new technology?<\/li>\n<li>HMW frame the guidelines around the process for writing new SC?<\/li>\n<li>HMW determine when new tech does not fit existing SC?<\/li>\n<li>HMW build the next generation of assistive technology?<\/li>\n<li>HMW be inspired by other code\/linking(?) tools and provide more flexibility?<\/li>\n<li>HMW make the conformance structure amenable to innovation?<\/li>\n<li>HMW strike a balance between comprehensiveness and concision?<\/li>\n<li>HMW cross pollinate between different parts of specification and allow things to have more than one home?<\/li>\n<li>HMW move forward and acknowledge standard might be wrong without invalidating it as a standard?<\/li>\n<li>HMW make public participation easier and more democratic?<\/li>\n<li>HMW be inspired by MDN?<\/li>\n<li>HMW make intent of each SC clear?<\/li>\n<li>HMW be inspired by web specification style?\n<ul>\n<li>Normative<\/li>\n<li>Non-normative<\/li>\n<li>Informative<\/li>\n<li>Examples<\/li>\n<\/ul>\n<\/li>\n<li>HMW \u201csocialize\u201d the guidelines?<\/li>\n<li>HMW make the contribution process more visible?<\/li>\n<li>HMW use GitHub in this process?<\/li>\n<li>HMW take inspiration from other democratic processes\/standards orgs(?)?<\/li>\n<li>HMW determine when a decision gets made?<\/li>\n<li>HMW make the judicial process more democratic?<\/li>\n<li>HMW structure to scale to new additions like COGA (+ ~ 70 SC)?<\/li>\n<li>HMW structure guidelines to be consumable by other tools?<\/li>\n<li>HMW make testing more deterministic? (Pass\/Fail)<\/li>\n<li>HMW show a11y is more impactful to the business than they think? Cheaper?<\/li>\n<li>HMW present guidelines as a resource for good design rather than rules to obey?<\/li>\n<li>HMW show how these guidelines improve the experience of real, non-theoretical people?<\/li>\n<li>HMW get these guidelines into a state easily consumable by tooling?<\/li>\n<li>HMW present the guidelines in a more digestible way?<\/li>\n<li>HMW get tech people clear on a11y principles to fill gap before specific guidelines can be written?<\/li>\n<li>HMW let people decide what is important to them?<\/li>\n<li>HMW provide potential strategies for integrating a11y into project process?<\/li>\n<li>HMW allow community members to contribute if they do not feel like \u201cexperts\u201d?<\/li>\n<li>Parse and chunk content in a way that supports scanning \/ reading in multiple ways?<\/li>\n<li>Find a global source \/ standard for \u201cplain language\u201d?<\/li>\n<li>Find a global source for statistics on each human problem?<\/li>\n<li>Assign a date to individual success criteria?<\/li>\n<li>Keep techniques open and not fixed?<\/li>\n<li>Reframe criteria as opportunities in support of problems?<\/li>\n<li>Place more emphasis on criteria currently designated as AAA?<\/li>\n<li>Identify and measure an individual preference?<\/li>\n<li>Keep multiple expert opinions in scope?<\/li>\n<li>Design onboarding to specs for multiple roles and disciplines?<\/li>\n<li>Tag content in a way that best supports humans and machines for search?<\/li>\n<li>Add accessibility to the patent process of new technology (content \/ assistive)?<\/li>\n<li>Create a system that enables content tech to make itself known to those that may need it?<\/li>\n<li>Make testing and validation contextual to a need and not a criteria?<\/li>\n<li>Use individual judgments as a voice of participation and contribution?<\/li>\n<li>Create a unit of measure that is not a binary pass \/ fail?<\/li>\n<li>Use the new ACT Rules doc format for human and manual testing?<\/li>\n<li>Eliminate the need for AT by greater feature \/ support of user agents?<\/li>\n<li>Have video players handle captions (not intimidating)?<\/li>\n<li>3D flythrough version of WCAG with person as aliens in cool adapted smart houses?<\/li>\n<li>Getting an editorial voice in plain language? Do that later.<\/li>\n<li>A\/B testing descriptions?<\/li>\n<li>Sprint too short for complex but necessary step (merge another problem space).<\/li>\n<li>Singular problem.<\/li>\n<li>Dry explanation of cause.<\/li>\n<li>Need acceptable implementations.<\/li>\n<li>Knowledge base (group tag)<\/li>\n<li>Build a corpus of test results to mine and review<\/li>\n<li>Describe broad base and when experts disagree<\/li>\n<li>Describe levels and testability<\/li>\n<li>Have human testing determine conflicts with other tests<\/li>\n<li>Include problems that don\u2019t fit a success criteria<\/li>\n<li>Standardise understanding of effects of disabilities<\/li>\n<li>Human testing (group tag)<\/li>\n<li>How (group tag)<\/li>\n<li>Report it using simple language<\/li>\n<li>Get the same results irrespective of who is testing<\/li>\n<li>Test setup environment and requirements<\/li>\n<li>Ensure tests cover the whole WCAG<\/li>\n<li>Have testing tools that are accessible<\/li>\n<li>Write the success criteria<\/li>\n<li>Support testing where the tester cannot do it alone<\/li>\n<li>Use the new ACT Rules Format for human testing<\/li>\n<li>Ensure experts and PwD as experts are certified?<\/li>\n<li>Create an alternative to certification to qualify humans for testing?<\/li>\n<li>Ensure PwD are part of testing?<\/li>\n<li>Resolve differences between peers?<\/li>\n<li>Create a peer review model that includes Pwd?<\/li>\n<li>Difficult to get started: \u201con-ramp\u201d, \u201croles\u201d, findability, clearer<\/li>\n<li>HMW meet everyone where they are. Something I can do and understand in my context<\/li>\n<li>HMW solve \u00a0the simple problems like Alt text, tables, etc.<\/li>\n<li>HMW make sure to connect to the goals from the start so people know why<\/li>\n<li>HMW teach the fundamentals in the right way\/right time<\/li>\n<li>HMW teach the basic things with support\/training material<\/li>\n<li>HMW progress from fundamentals to more complex issues<\/li>\n<li>HMW fundamental module that covers basics\/tools\/ etc.<\/li>\n<li>HMW make using Silver a good experience<\/li>\n<li>Flexibility: Adapt to new tech and new barriers to PwD<\/li>\n<li>Flexible Process<\/li>\n<li>Governance: Easier updating, learn from others, faster response to new demands<\/li>\n<li>HMW Have a moore flexible view of the conformance. \u201cSubstantially meets\u201d<\/li>\n<li>HMW get Silver to connect meaningfully<\/li>\n<li>HMW Define the requirements for WCAG so they are both clear and flexible<\/li>\n<li>Publish conformance not in VPAT<\/li>\n<li>HMW avoid being so picky about the small things<\/li>\n<li>HMW focus WCAG on the lived user experience instead of the tech requirements<\/li>\n<li>HMW focus on tasks not pages<\/li>\n<li>How we set pass\/fail levels<\/li>\n<li>HMW test meaningfully<\/li>\n<li>HMW get the lawyers out of the center of WCAG compliance<\/li>\n<li>Ambiguity in Interpreting the Success Criteria &#8211; agreement about exp, level of abstraction, difficulty of learning success criteria<\/li>\n<li>HMW be open to multiple possibilities<\/li>\n<li>HMW embrace the ambiguity in performance<\/li>\n<li>HMW let people what\u2019s important to them<\/li>\n<li>HMW Avoid the cul-de-sac of consistency. \u00a0(See CUE in usability)<\/li>\n<li>HMW help testers understand users not tests.<\/li>\n<li>HMW see a11y as UX for a wider range of people<\/li>\n<li>HMW not focus so much on screen readers<\/li>\n<li>HMW find connection to prefs for all and not just AT.<\/li>\n<li>HMW create usability requests(?) not conformance.<\/li>\n<li>HMW separate content conformance from user agent and AT provider (?)<\/li>\n<li>HMW place needs of users first<\/li>\n<li>HMW differentiate between removing barriers and optimizing experience<\/li>\n<li>HMW prioritize barriers then enhanced experience.<\/li>\n<li>HMW hold AT to the same standards as the \u201ccontent\u201d<\/li>\n<li>HMW connect regs to guidelines and principles so they are testable in an understood context.<\/li>\n<li>\u00a0Think about domain<\/li>\n<li>HMW Be flexible about conformance depending on the context of use<\/li>\n<li>Accountable<\/li>\n<li>Text all the players: content\/ UA\/ AT<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Silver Design Sprint Report W3C Community Group Report 23 April 2018 Latest version https:\/\/www.w3.org\/community\/silver\/draft-final-report-of-silver\/ Editor: Jeanne Spellman Copyright \u00a9 2018 the Contributors to the Report Silver Design Sprint, published by the\u00a0Silver Community Group\u00a0under the\u00a0W3C Community Contributor License Agreement (CLA). A &hellip; <a href=\"https:\/\/www.w3.org\/community\/silver\/draft-final-report-of-silver\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":94,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_s2mail":"","footnotes":""},"class_list":["post-87","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.w3.org\/community\/silver\/wp-json\/wp\/v2\/pages\/87","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.w3.org\/community\/silver\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.w3.org\/community\/silver\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/silver\/wp-json\/wp\/v2\/users\/94"}],"replies":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/silver\/wp-json\/wp\/v2\/comments?post=87"}],"version-history":[{"count":17,"href":"https:\/\/www.w3.org\/community\/silver\/wp-json\/wp\/v2\/pages\/87\/revisions"}],"predecessor-version":[{"id":115,"href":"https:\/\/www.w3.org\/community\/silver\/wp-json\/wp\/v2\/pages\/87\/revisions\/115"}],"wp:attachment":[{"href":"https:\/\/www.w3.org\/community\/silver\/wp-json\/wp\/v2\/media?parent=87"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}