Skip to content

Commit

Permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Clean up some indentation
Browse files Browse the repository at this point in the history
patrickhlauke committed Mar 23, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
1 parent c87ea1f commit 3a11fbd
Showing 3 changed files with 253 additions and 287 deletions.
173 changes: 73 additions & 100 deletions conformance-challenges/index.html
Original file line number Diff line number Diff line change
@@ -4,9 +4,9 @@
<meta charset="UTF-8" />
<title>Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c-common" class="remove"></script>
<script src="../script/wcag.js" class="remove"></script>
<script src="respec-config.js" class="remove"></script>
<script src="../biblio.js" class="remove"></script>
<script src="../script/wcag.js" class="remove"></script>
<script src="respec-config.js" class="remove"></script>
<script src="../biblio.js" class="remove"></script>
<link rel="stylesheet" type="text/css" href="../css/sources.css" class="remove" />
<style>
.silver {
@@ -17,14 +17,14 @@
font-weight: bold;
font-size: 110%;
}
q {
color: darkred;
}
q {
color: darkred;
}
</style>
</head>
<body>
<section id="abstract">

<!--
<div class ="ednote">
<p>Publication as a Working Draft does not necessarily represent a consensus of the Working Group and does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>
@@ -33,25 +33,19 @@
This draft is published to obtain public review of the issues identified and solutions proposed. </p>
</div>
-->

<p>This document explores the page-based conformance verification approach used by WCAG 2.0 and 2.1 accessibility guidelines. It explains how this approach is challenging to apply to certain websites and web applications.
It also explores ideas on how future versions of guidelines might address these challenges.
This document focuses primarily on challenges to large, highly complex, dynamic sites.
Other efforts in WAI are looking at different aspects of conformance for other types of sites.</p>

<p>The challenges covered broadly fall into five main areas:</p>
<ol>
<li>Numerous provisions need human involvement to test and verify conformance, which is especially challenging to scale for <a>large websites</a> and for <a>dynamic websites</a>;</li>
<li>Large and dynamic sites with their changing permutations may be difficult to validate;</li>
<li>Third parties frequently add and change content on large and dynamic sites;</li>
<li>Numerous provisions need human involvement to test and verify conformance, which is especially challenging to scale for <a>large websites</a> and for <a>dynamic websites</a>;</li>
<li>Large and dynamic sites with their changing permutations may be difficult to validate;</li>
<li>Third parties frequently add and change content on large and dynamic sites;</li>
<li>Applying a web-based, and page-based conformance model can be challenging to do for non-web Information and Communications Technologies (ICT).</li>
<li>The centrality of <q>Accessibility Supported</q> in the many provisions
tied to use with assistive technologies and platform accessibility
features, combined with the lack of definition of what constitutes
Accessibility Supported, further exacerbates the need for expert
human judgement (#1 above), as well as potential different and
non-overlapping sets of these features used when including 3rd
party content (#3 above).</li>
<li>The centrality of <q>Accessibility Supported</q> in the many provisions tied to use with assistive technologies and platform accessibility features, combined with the lack of definition of what constitutes Accessibility Supported, further exacerbates the need for expert human judgement (#1 above), as well as potential different and non-overlapping sets of these features used when including 3rd party content (#3 above).</li>
</ol>
<p>The purpose of this document is to help understand those challenges more holistically, and explore approaches for mitigating them so that we can address such
challenges more fully in future accessibility guidelines including the forthcoming <a href="https://www.w3.org/WAI/wcag3">W3C Accessibility Guidelines (WCAG 3.0)</a> (now in early development) where the <a href="https://www.w3.org/2019/12/ag-charter.html#scope">W3C Working Group Charter</a> expressly anticipates a new conformance model.</p>
@@ -199,47 +193,45 @@ <h3>Mitigation Approaches</h3>
<h3>Goals</h3>

<p>This document has two key goals:</p>
<ol>
<li>To develop, catalog, and characterize the challenges with accessibility guidelines conformance, and conformance verification that have arisen both through the multi-year research process preceding work on <a href="https://www.w3.org/WAI/wcag3">W3C Accessibility Guidelines (WCAG 3.0)</a> which have been in development under the name <q>Silver,</q> as well as through active discussion in the <a href="https://www.w3.org/WAI/GL/task-forces/silver/wiki/Substantial_Conformance">Silver Conformance Options Subgroup</a>.</li>
<li>To develop, catalog, and characterize mitigation approaches to these challenges, so that websites can be as accessible as possible and better assessed for accessibility to visitors with disabilities.</li>
</ol>
<ol>
<li>To develop, catalog, and characterize the challenges with accessibility guidelines conformance, and conformance verification that have arisen both through the multi-year research process preceding work on <a href="https://www.w3.org/WAI/wcag3">W3C Accessibility Guidelines (WCAG 3.0)</a> which have been in development under the name <q>Silver,</q> as well as through active discussion in the <a href="https://www.w3.org/WAI/GL/task-forces/silver/wiki/Substantial_Conformance">Silver Conformance Options Subgroup</a>.</li>
<li>To develop, catalog, and characterize mitigation approaches to these challenges, so that websites can be as accessible as possible and better assessed for accessibility to visitors with disabilities.</li>
</ol>

<p>A better understanding of the situations in which the
WCAG 2.x conformance model may be difficult to apply could lead to more effective conformance models
and testing approaches in the future.</p>

<p>It is important to recognize that success criteria in WCAG 2.x are quite distinct from the conformance model. These criteria describe approaches to content accessibility that are thoughtfully designed to enable people with a broad range of disabilities to effectively consume and interact with web content. Challenges with the conformance model do not in any way invalidate the criteria. For example, while requiring human judgment to validate a page limits testing to sampling of templates, flows, and top tasks, etc. (see <a href="#Challenge-1">Challenge #1 below</a>), without that human judgement it may not be possible to deliver a page that makes sense to someone with a disability. Similarly, while it may not be possible to know that all third party content is fully accessible (see <a href="#Challenge-3">Challenge #3 below</a>), without review of that content by someone sufficiently versed in accessibility it may not be possible to be sure that pages containing third party content fully conform to WCAG 2.x. Human judgement is a core part of much of WCAG 2.x for good reasons, and the challenges that arise from it are important to successfully grapple with.</p>
</section>
<section class="introductory">
</section>
<section class="introductory">
<h3>Additional Background</h3>
<p>This document is published to seek additional contributions from the wider web community on:</p>
<ul>
<li>Any additional challenges, or further illustration of challenges in the existing identified areas below;</li>
<li>Contributions to the mitigation approaches, and questions or concerns about the mitigation approaches;</li>
</ul>
<p>We seek to gain a thorough understanding of the challenges faced by large, complex, and dynamic websites who are attempting to provide accessible services to their web site users. It is expected that a more thorough understanding of these challenges can lead to either a new conformance model, or an alternative model that is more appropriate for large, complex, and/or dynamic websites (in <a href="https://www.w3.org/WAI/wcag3">WCAG 3.0</a>).</p>
<p>This document is published to seek additional contributions from the wider web community on:</p>
<ul>
<li>Any additional challenges, or further illustration of challenges in the existing identified areas below;</li>
<li>Contributions to the mitigation approaches, and questions or concerns about the mitigation approaches;</li>
</ul>
<p>We seek to gain a thorough understanding of the challenges faced by large, complex, and dynamic websites who are attempting to provide accessible services to their web site users. It is expected that a more thorough understanding of these challenges can lead to either a new conformance model, or an alternative model that is more appropriate for large, complex, and/or dynamic websites (in <a href="https://www.w3.org/WAI/wcag3">WCAG 3.0</a>).</p>

<p class="silver">This document also includes previously published research from the Silver Task Force and Community Group that is related to Challenges with Accessibility Guidelines Conformance and Testing. There is some
overlap between the challenges captured in this published research and the challenges enumerated in the first 4 sections of this document. The research findings have been folded into other sections of this document as appropriate.
</p>
<p class="silver">This document also includes previously published research from the Silver Task Force and Community Group that is related to Challenges with Accessibility Guidelines Conformance and Testing. There is some overlap between the challenges captured in this published research and the challenges enumerated in the first 4 sections of this document. The research findings have been folded into other sections of this document as appropriate.</p>

<p class="mitigation">Also present in this document is an introductory discussion of approaches to mitigate the impact of the challenges cited that have been suggested by various stakeholders. We are publishing this updated draft now to continue seeking wide review to further catalogue and characterize the challenges and mitigation approaches, so that this work can become input into <a href="https://www.w3.org/WAI/wcag3">W3C accessibility guidelines (WCAG 3.0)</a>.
<p class="mitigation">Also present in this document is an introductory discussion of approaches to mitigate the impact of the challenges cited that have been suggested by various stakeholders. We are publishing this updated draft now to continue seeking wide review to further catalogue and characterize the challenges and mitigation approaches, so that this work can become input into <a href="https://www.w3.org/WAI/wcag3">W3C accessibility guidelines (WCAG 3.0)</a>.
</p>
</section>
</section>

<section class="introductory">
<h2>Key Terms</h2>
<p>The following terms are used in this document:</p>
<dl>
<dt><dfn>large websites</dfn></dt>
<dd>Websites with thousands of pages, let alone hundreds of thousands or more.</dd>
<dt><dfn>dynamic websites</dfn></dt>
<dd>Websites that are constantly being updated with new content, possibly hundreds of times an hour, or even thousands of times per second.</dd>
<dt><dfn>complex websites</dfn></dt>
<dd>Web apps that are similar in scope to complex desktop applications (e.g. a full-fledged spreadsheet or word processor web application). Or websites with a large portion of pages that are generated upon demand, pulling from dozens (or more) different content sources.</dd>
</dl>
</section>
<section class="introductory">
<h2>Key Terms</h2>
<p>The following terms are used in this document:</p>
<dl>
<dt><dfn>large websites</dfn></dt>
<dd>Websites with thousands of pages, let alone hundreds of thousands or more.</dd>
<dt><dfn>dynamic websites</dfn></dt>
<dd>Websites that are constantly being updated with new content, possibly hundreds of times an hour, or even thousands of times per second.</dd>
<dt><dfn>complex websites</dfn></dt>
<dd>Web apps that are similar in scope to complex desktop applications (e.g. a full-fledged spreadsheet or word processor web application). Or websites with a large portion of pages that are generated upon demand, pulling from dozens (or more) different content sources.</dd>
</dl>
</section>
<section id="Challenge-1">
<h2>Challenge #1: Scaling Conformance Verification</h2>
<p>A challenge common to many success criteria is the inability for automatic testing to fully validate conformance and the subsequent time, cost, and expertise needed to perform the necessary manual test to cover the full range of the requirements.
@@ -249,30 +241,13 @@ <h2>Challenge #1: Scaling Conformance Verification</h2>

<p><a href="#Appendix-A">Appendix A</a> describes challenges with applying the WCAG 2.x conformance model to specific Guidelines and Success Criteria, primarily based on required human involvement in evaluation of conformance to them. The list is not exhaustive, but it covers the preponderance of known challenges with all A and AA Success Criteria.</p>
<section class="silver">
<h3>Silver Research Findings</h3>
<p>Silver research identified two further challenges related to scaling conformance verification:</p>

<ul>
<li>In <a
href="#testing-constraints">Constraints on <q>What is Strictly Testable</q></a>
Silver finds that <q>The requirement for valid and reliable testability for WCAG success criteria presents a structural barrier to including the needs of people with disabilities whose needs are not
strictly testable.</q> User needs such as thos articulated by the W3C&apos;s <a href="http://www.w3.org/WAI/GL/task-forces/coga/">Cognitive and Learning Disabilities (COGA) Task Force</a> in their extensive W3C Note publication <a href="https://www.w3.org/TR/coga-usable/">Making content usable for people with cognitive and learning disabilities</a> [[coga-usable]] only expand and exacerbate the need for expert human testing. As silver also notes: <q>The entire principle of understandable is critical for people with cognitive disabilities, yet success criteria
intended to support the principle are not easy to test for or clear on how to measure.</q>
</li>

<li>Silver also finds that <a href="#human-testable">Human evaluation</a> does not
yield consistent conclusions: <q>Regardless of proficiency,
there is a significant gap in how any two human
auditors will identify a success or fail of criteria.
&#x2026; Ultimately, there is variance between: any two
auditors; &#x2026; Because there&apos;s so much room for human
error, an individual may believe they&apos;ve met a specific
conformance model when, in reality, that&apos;s not the
case. &#x2026; There isn&apos;t a standardized approach to how
the conformance model applies to success criteria at
the organizational level and in specific test case
scenarios.</q></li>
</ul>
<h3>Silver Research Findings</h3>
<p>Silver research identified two further challenges related to scaling conformance verification:</p>

<ol>
<li>In <a href="#testing-constraints">Constraints on <q>What is Strictly Testable</q></a> Silver finds that <q>The requirement for valid and reliable testability for WCAG success criteria presents a structural barrier to including the needs of people with disabilities whose needs are not strictly testable.</q> User needs such as thos articulated by the W3C&apos;s <a href="http://www.w3.org/WAI/GL/task-forces/coga/">Cognitive and Learning Disabilities (COGA) Task Force</a> in their extensive W3C Note publication <a href="https://www.w3.org/TR/coga-usable/">Making content usable for people with cognitive and learning disabilities</a> [[coga-usable]] only expand and exacerbate the need for expert human testing. As silver also notes: <q>The entire principle of understandable is critical for people with cognitive disabilities, yet success criteria intended to support the principle are not easy to test for or clear on how to measure.</q></li>
<li>Silver also finds that <a href="#human-testable">Human evaluation</a> does not yield consistent conclusions: <q>Regardless of proficiency, there is a significant gap in how any two human auditors will identify a success or fail of criteria. &#x2026; Ultimately, there is variance between: any two auditors; &#x2026; Because there&apos;s so much room for human error, an individual may believe they&apos;ve met a specific conformance model when, in reality, that&apos;s not the case. &#x2026; There isn&apos;t a standardized approach to how the conformance model applies to success criteria at the organizational level and in specific test case scenarios.</q></li>
</ol>
</section>

<section class="mitigation">
@@ -325,11 +300,9 @@ <h3>Treatment of 3rd party content and Statements of Partial Conformance</h3>
Partial Conformance</a>. [[wcag21]] It provides two options for such content — that
pages with 3rd party content may:</p>
<ol>
<li>Make a determination of conformance <q>based on best knowledge,</q> for example
by monitoring and repairing non-conforming content within 2 business days;
<li>Make a determination of conformance <q>based on best knowledge,</q> for example by monitoring and repairing non-conforming content within 2 business days;
or</li>
<li>Make a statement of partial conformance if the page could conform if the
3rd party content were removed.</li>
<li>Make a statement of partial conformance if the page could conform if the 3rd party content were removed.</li>
</ol>
<p>The provision of monitoring and required repair within a 2 business day
window doesn&apos;t address the underlying challenge of pages with (3rd party)
@@ -433,7 +406,7 @@ <h2>Challenge #5: Accessibility Supported</h2>
<p>The
<a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-supported-definition-head">
first Note under the definition of Accessibility Supported</a> states that: <q>The WCAG Working
group and the W3C do not specify which or how much support by assistive
group and the W3C do not specify which or how much support by assistive
technologies there must be for a particular use of a Web technology in
order for it to be classified as accessibility supported.</q>
This is further expanded upon in the section
@@ -442,7 +415,7 @@ <h2>Challenge #5: Accessibility Supported</h2>
<q>This topic raises the question of how many
or which assistive technologies must support a Web technology in order
for that Web technology to be considered <q>accessibility supported.</q> The
WCAG Working group and the W3C do not specify which or how many
WCAG Working group and the W3C do not specify which or how many
assistive technologies must support a Web technology in order for it to
be classified as accessibility supported. This is a complex topic and
one that varies both by environment and by language.</q></p>
@@ -1202,7 +1175,7 @@ <h4>Definition of Conformance</h4>
<li>Complete Process</li>
<li>Only "Accessibility-supported" ways of using technologies</li>
<li>Non-Interference: Technologies that are not accessibility supported can be used, as long as all the information is also available using technologies that are accessibility supported and as long as the non-accessibility-supported material does not interfere.</li>
</ol></blockquote>
</ol></blockquote>
</section>
<section id="3rd">
<h4>Themes from Research</h4>
@@ -1217,21 +1190,21 @@ <h4>Themes from Research</h4>
</li>

<li>Specific success criteria for failure - 1.1.1 , 2.2., 4.1.2 (Keith et al., 2012)</li>
<li><q>Reliably Human Testable,</q> <q>not reliably testable</q> <a href="http://www.researchgate.net/publication/235339930_Is_accessibility_conformance_an_elusive_property_A_study_of_validity_and_reliability_of_WCAG_20">Is Accessibility Conformance an Elusive Property? (Brajnik et al. 2012)</a>, found the average agreement was at the 70-75% mark, while the error rate was around 29%.
<li><q>Reliably Human Testable,</q> <q>not reliably testable</q> <a href="http://www.researchgate.net/publication/235339930_Is_accessibility_conformance_an_elusive_property_A_study_of_validity_and_reliability_of_WCAG_20">Is Accessibility Conformance an Elusive Property? (Brajnik et al. 2012)</a>, found the average agreement was at the 70-75% mark, while the error rate was around 29%.
<ul>
<li>Expertise appears to improve (by 19%) the ability to avoid false positives. Finally, pooling the results of two independent experienced evaluators would be the best option, capturing at most 76% of the true problems and producing only 24% of false positives. Any other independent combination of audits would achieve worse results.</li>
<li>This means that an 80% target for agreement, when audits are conducted without communication between evaluators, is not attainable, even with experienced evaluators.</li>
</ul>
</li>
<li>Challenges and Recommendations (Alonso et al., 2010)
<ul>
<li><q>accessibility supported ways of using technologies</q></li>
<li><q>accessibility supported ways of using technologies</q></li>
<li>Testability of Success Criteria</li>
<li>Openness of Techniques and Failures</li>
<li>Aggregation of Partial Results</li>
</ul>
</li>
<li>Silver needs to expand the scope beyond web to include apps, documents, authoring, user agents, wearables, kiosks, IoT, VR, etc. and be inclusive of more disabilities. (<abbr title="user experience">UX</abbr> Professionals Use of WCAG: Analysis)</li>
<li>Silver needs to expand the scope beyond web to include apps, documents, authoring, user agents, wearables, kiosks, IoT, VR, etc. and be inclusive of more disabilities. (<abbr title="user experience">UX</abbr> Professionals Use of WCAG: Analysis)</li>
<li>Accessibility Supported allows inadequate assistive technologies to be claimed for conformance, particularly in non-native English speaking countries. (Interviews on Conformance)</li>
</ul>
</section>
@@ -1269,25 +1242,25 @@ <h4>Evolving Technology</h4>

<section class="appendix" id="Appendix-D">
<h2>Acknowledgments</h2>
<section>
<h3>Participants of the AG WG who contributed to the development of this document:</h3>
<ul>
<li>Charles Adams (Oracle)</li>
<li>Alastair Campbell (Nomensa)</li>
<li>Michael Cooper (W3C)</li>
<li>Joe Cronin (Amazon)</li>
<li>Detlev Fischer (Invited Expert) </li>
<li>Charles Hall (Invited Expert)</li>
<li> Andrew Kirkpatrick (Adobe)</li>
<li>Peter Korn (Amazon)</li>
<li>Shawn Lauriat (Google)</li>
<li> Mary Jo Mueller (IBM)</li>
<li>Janina Sajka (Invited Expert; Was Amazon until 14 November 2021)</li>
<li>Jeanne Spellman (TetraLogical)</li>
<li>Jason White (ETS)</li>
</ul>
</section>
<div data-include="../acknowledgements/funders.html" data-include-replace="true"></div>
<section>
<h3>Participants of the AG WG who contributed to the development of this document:</h3>
<ul>
<li>Charles Adams (Oracle)</li>
<li>Alastair Campbell (Nomensa)</li>
<li>Michael Cooper (W3C)</li>
<li>Joe Cronin (Amazon)</li>
<li>Detlev Fischer (Invited Expert) </li>
<li>Charles Hall (Invited Expert)</li>
<li>Andrew Kirkpatrick (Adobe)</li>
<li>Peter Korn (Amazon)</li>
<li>Shawn Lauriat (Google)</li>
<li>Mary Jo Mueller (IBM)</li>
<li>Janina Sajka (Invited Expert; Was Amazon until 14 November 2021)</li>
<li>Jeanne Spellman (TetraLogical)</li>
<li>Jason White (ETS)</li>
</ul>
</section>
<div data-include="../acknowledgements/funders.html" data-include-replace="true"></div>
</section>
</body>
</html>
47 changes: 23 additions & 24 deletions understanding/21/content-on-hover-or-focus.html
Original file line number Diff line number Diff line change
@@ -15,17 +15,16 @@ <h2>In brief</h2>
<dt>What to do</dt><dd>If hover or focus causes content changes, ensure interaction is predictable.</dd>
<dt>Why it's important</dt><dd>Unpredictable temporary content can be hard for some to consume and may disrupt others.</dd>
</dl>

</section>

<section id="intent">
<h2>Intent</h2>
<p>Additional content that appears and disappears in coordination with keyboard focus or pointer hover often leads to accessibility issues. Reasons for such issues include:</p>
<ul>
<li>the user may not have intended to trigger the interaction</li>
<li>the user may not know new content has appeared</li>
<li>the new content may intefere with a user's ability to do a task</li>
</ul>
<li>the user may not have intended to trigger the interaction</li>
<li>the user may not know new content has appeared</li>
<li>the new content may intefere with a user's ability to do a task</li>
</ul>

<p>Examples of such interactions can include custom tooltips, sub-menus and other nonmodal popups which display on hover and focus. The intent of this success criterion is to ensure that authors who cause additional content to appear and disappear in this manner must design the interaction in such a way that users can:</p>
<ul>
@@ -45,10 +44,10 @@ <h2>Intent</h2>
<h3>Dismissable</h3>
<p>The intent of this condition is to ensure that the additional content does not interfere with viewing or operating the page's original content. When magnified, the portion of the page visible in the viewport can be significantly reduced. Mouse users frequently move the pointer to pan the magnified viewport and display another portion of the screen. However, almost the entire portion of the page visible in this restricted viewport may trigger the additional content, making it difficult for a user to pan without re-triggering the content. A keyboard means of dismissing the additional content provides a workaround.</p>
<p>Alternatively, low vision users who can only navigate via the keyboard do not want the small area of their magnified viewport cluttered with hover text. They need a keyboard method of dismissing something that is obscuring the current focal area.</p>
<p>Two methods may be used to satisfy this condition and prevent such interference:</p>
<p>Two methods may be used to satisfy this condition and prevent such interference:</p>
<ol>
<li>Position the additional content so that it does not obscure any other content including the trigger, with the exception of white space and purely decorative content, such as a background graphic which provides no information.</li>
<li>Provide a mechanism to easily dismiss the additional content, such as by pressing Escape.</li>
<li>Position the additional content so that it does not obscure any other content including the trigger, with the exception of white space and purely decorative content, such as a background graphic which provides no information.</li>
<li>Provide a mechanism to easily dismiss the additional content, such as by pressing Escape.</li>
</ol>
<p>For most triggers of relatively small size, it is desirable for both methods to be implemented. If the trigger is large, noticing the additional content may be of concern if it appears away from the trigger. In those cases, only the second method may be appropriate.</p>
<p>The success criterion allows for input error messages to persist as there are cases that require attention, explicit confirmation or remedial action.</p>
@@ -62,34 +61,34 @@ <h3>Hoverable</h3>
<h3>Persistent</h3>
<p>The intent of this condition is to ensure users have adequate time to perceive the additional content after it becomes visible. Users with disabilities may require more time for many reasons, such as to change magnification, move the pointer, or simply to bring the new content into their visual field. Once it appears, the content should remain visible until:</p>
<ul>
<li>The user removes hover or focus from the trigger and the additional content, consistent with the typical user experience;</li>
<li>The user dismisses the additional content via the mechanism provided to satisfy the Dismissable condition; or</li>
<li>The information conveyed by the additional content becomes invalid, such as a 'busy' message that is no longer valid.</li>
<li>The user removes hover or focus from the trigger and the additional content, consistent with the typical user experience;</li>
<li>The user dismisses the additional content via the mechanism provided to satisfy the Dismissable condition; or</li>
<li>The information conveyed by the additional content becomes invalid, such as a 'busy' message that is no longer valid.</li>
</ul>
</section>
<section>
<h3>Additional Notes</h3>
<ul>
<li>This criterion does not attempt to solve such issues when the appearance of the additional content is completely controlled by the user agent. A prominent example is the common behavior of browsers to display the <code>title</code>  attribute in HTML as a small tooltip.</li>
<li>Modal dialogs are out of scope for this criterion because they must take keyboard focus and thus should not appear on hover or focus. Refer to <a href="https://www.w3.org/TR/WCAG21/#on-focus">Success Criterion 3.2.1, On Focus</a>.</li>
<li>Content which can be triggered via pointer hover should also be able to be triggered by keyboard focus. Refer to <a href="https://www.w3.org/TR/WCAG21/#keyboard">Success Criterion 2.1.1, Keyboard</a>.</li>
<li>This criterion does not attempt to solve such issues when the appearance of the additional content is completely controlled by the user agent. A prominent example is the common behavior of browsers to display the <code>title</code>  attribute in HTML as a small tooltip.</li>
<li>Modal dialogs are out of scope for this criterion because they must take keyboard focus and thus should not appear on hover or focus. Refer to <a href="https://www.w3.org/TR/WCAG21/#on-focus">Success Criterion 3.2.1, On Focus</a>.</li>
<li>Content which can be triggered via pointer hover should also be able to be triggered by keyboard focus. Refer to <a href="https://www.w3.org/TR/WCAG21/#keyboard">Success Criterion 2.1.1, Keyboard</a>.</li>
</ul>
</section>
</section>
<section id="benefits">

<section id="benefits">
<h2>Benefits</h2>
<ul>
<li>Users with low vision who view content under magnification will be better able to view content on hover or focus without reducing their desired magnification.</li>
<li>Users who increase the size of mouse cursors via platform settings or assistive technology will be able to employ a technique to view obscured content on hover.</li>
<li>Users with low vision or cognitive disabilities will have adequate time to perceive additional content appearing on hover or focus and to view the trigger content with less distraction.</li>
<li>users with low pointer accuracy will be able to more easily dismiss unintentionally-triggered additional content</li>
<li>Users with low vision who view content under magnification will be better able to view content on hover or focus without reducing their desired magnification.</li>
<li>Users who increase the size of mouse cursors via platform settings or assistive technology will be able to employ a technique to view obscured content on hover.</li>
<li>Users with low vision or cognitive disabilities will have adequate time to perceive additional content appearing on hover or focus and to view the trigger content with less distraction.</li>
<li>users with low pointer accuracy will be able to more easily dismiss unintentionally-triggered additional content</li>
</ul>
</section>

<section id="examples">
<h2>Examples</h2>

<section class="example">
<h3>Example 1: Dismissable Tooltip</h3>
<figure id="figure-mouse-tooltip-below">
@@ -102,7 +101,7 @@ <h3>Example 1: Dismissable Tooltip</h3>
<figcaption>The button's tooltip also appears on focus and can be removed with the Escape key. The screen shot shows the same LVTF button with focus, but the tooltip has been dismissed and is no longer visible.</figcaption>
</figure>
</section>

<section class="example">
<h3>Example 2: Hoverable Tooltip</h3>
<figure id="figure-large-pointer-tooltip">
@@ -119,7 +118,7 @@ <h2>Resources</h2>
<li><a href="https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/">Tooltip design described in WAI-ARIA Authoring Practices</a></li>
</ul>
</section>

<section id="techniques">
<h2>Techniques</h2>
<section id="sufficient">
320 changes: 157 additions & 163 deletions understanding/21/text-spacing.html
Original file line number Diff line number Diff line change
@@ -1,175 +1,169 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="UTF-8" />
<title>Understanding Text Spacing</title>
<link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove" />
</head>
<body>
<h1>Understanding Text Spacing</h1>
<head>
<meta charset="UTF-8" />
<title>Understanding Text Spacing</title>
<link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove" />
</head>
<body>
<h1>Understanding Text Spacing</h1>

<section id="brief">
<h2>In brief</h2>
<dl>
<dt>Goal</dt><dd>Users can adjust text spacing to make it easier to read.</dd>
<dt>Author task</dt><dd>Ensure content adapts to user-defined text settings.</dd>
<dt>Why it's important</dt><dd>Some people need text with different spacing or font characteristics.</dd>
</dl>

</section>
<section id="intent">
<h2>Intent</h2>
<p>The intent of this Success Criterion (SC) is to ensure that when people override author specified text spacing to improve their reading experience, content is still readable and operable. Each of the requirements stipulated in the SC's four bullets helps ensure text styling can be adapted by the user to suit their needs.</p>
<p>The specified metrics set a minimum baseline. The values in between the author's metrics and the metrics specified in this SC should not have loss of content or functionality.</p>
<p>This SC focuses on the adaptability of content to an increase in spacing between lines, words, letters, and paragraphs. Any combination of these may assist a user with effectively reading text. As well, ensuring that content correctly adapts when users override author settings for spacing also significantly increases the likelihood other style preferences can be set by the user. For example, a user may need to change to a wider font family than the author has set in order to effectively read text. </p>
<section>
<h3 id="authorresp">Author Responsibility </h3>
<p>This SC does not dictate that authors must set all their content to the specified metrics, nor does the SC intend to imply that all users will adjust the specified metrics. Rather, it specifies that should a user choose to set any of these metrics they can do so without any loss of content or functionality. The author requirement is both to not interfere with a user's ability to override the author settings, and to ensure that content thus modified does not break content in the manners shown in figures 1 through 3 in Effects of Not Allowing for Spacing Override.</p>
<section id="brief">
<h2>In brief</h2>
<dl>
<dt>Goal</dt><dd>Users can adjust text spacing to make it easier to read.</dd>
<dt>Author task</dt><dd>Ensure content adapts to user-defined text settings.</dd>
<dt>Why it's important</dt><dd>Some people need text with different spacing or font characteristics.</dd>
</dl>
</section>
<section id="intent">
<h2>Intent</h2>
<p>The intent of this Success Criterion (SC) is to ensure that when people override author specified text spacing to improve their reading experience, content is still readable and operable. Each of the requirements stipulated in the SC's four bullets helps ensure text styling can be adapted by the user to suit their needs.</p>
<p>The specified metrics set a minimum baseline. The values in between the author's metrics and the metrics specified in this SC should not have loss of content or functionality.</p>
<p>This SC focuses on the adaptability of content to an increase in spacing between lines, words, letters, and paragraphs. Any combination of these may assist a user with effectively reading text. As well, ensuring that content correctly adapts when users override author settings for spacing also significantly increases the likelihood other style preferences can be set by the user. For example, a user may need to change to a wider font family than the author has set in order to effectively read text. </p>
<section>
<h3 id="authorresp">Author Responsibility </h3>
<p>This SC does not dictate that authors must set all their content to the specified metrics, nor does the SC intend to imply that all users will adjust the specified metrics. Rather, it specifies that should a user choose to set any of these metrics they can do so without any loss of content or functionality. The author requirement is both to not interfere with a user's ability to override the author settings, and to ensure that content thus modified does not break content in the manners shown in figures 1 through 3 in Effects of Not Allowing for Spacing Override.</p>

<p>In some human languages and scripts, some of the metrics specified by the SC are inapplicable. For example, languages such as Japanese do not use spacing following paragraphs, meaning that users are unlikely to make any paragraph spacing changes in practice. The exception in this SC allows authors to ignore text style properties which are inapplicable to the combination of language and script being used.</p>
<p>In some human languages and scripts, some of the metrics specified by the SC are inapplicable. For example, languages such as Japanese do not use spacing following paragraphs, meaning that users are unlikely to make any paragraph spacing changes in practice. The exception in this SC allows authors to ignore text style properties which are inapplicable to the combination of language and script being used.</p>

<p>It is beneficial for users if authors use any locally available guidance for improving readability in the local language or writing system. If the user chooses to go beyond the metrics specified, any resulting loss of content or functionality is the user's responsibility.</p>

<p>Further, this SC is not concerned with <em>how</em> users change the line height and spacing metrics. It does not require that content implement its own mechanisms to allow users to do this. It is not a failure of the content if a user agent or platform does not provide a way for users to do this. Content does not fail this SC if the method chosen by the user - for instance, the use of an extension or bookmarklet - fails to correctly set the line height and spacing text properties on the content (provided that the content is not actively and purposely preventing the properties from being added).</p>
<section>
<h4 id="applicability">Applicability</h4>
<p>If the markup-based technologies being used are capable of overriding text to the Success Criterion's metrics, then this SC is applicable. For instance Cascading Style Sheet/HTML technologies are quite able to allow for the specified spacing metrics. Plugin technologies would need to have a built-in ability to modify styles to the specified metrics. Currently, this SC does not apply to PDF as it is not implemented using markup.</p>
<p>Examples of text that are typically not affected by <a>style properties</a> and not expected to adapt are:</p>
<ul>
<li>Video captions embedded directly into the video frames and not provided as an associated caption file</li>
<li><a>Images of text</a></li>
</ul>
<p>For this SC, <a href="https://html.spec.whatwg.org/multipage/canvas.html#the-canvas-element">canvas</a> implementations of text are considered to be <a>images of text</a>.</p>
</section>
<section>
<h4 id="ellipses">Use of ellipses</h4>
<p>There may be regions of a page where text containers cannot expand due to design constraints (such as a maximum width for the left navigation or table column headers). A common convention if text exceeds its space is to replace truncated text with an ellipsis. Where ellipses appear as a result of modifying text style properties, the page can still meet the Text Spacing requirements, so long as the content is still available. For example:</p>
<ul>
<li>a mechanism is provided to reveal the truncated text on the page (for instance, the text appears on focus or on activation)</li>
<li>where the ellipsis is part of a section of
content which includes a link, the truncated text is revealed on the linked page</li>
</ul>

<p>Where text is not truncated but it is when text is spaced, if there is no mechanism to show the truncated text, it fails this Success Criterion.</p>
</section>
</section>
<section>
<h3 id="userresp">User Responsibility</h3>
<p>The ability to read and derive meaning from the overridden spacing rests with the user. The user may choose to exceed the spacing adjustments in the SC. If the increased spacing causes loss of content or functionality, the user will adjust or return to the author’s original spacing or spacing within the bounds of the SC. Regardless, the user needs the flexibility to adjust spacing within the bounds set in the SC without loss of content or functionality. Such changes may be achieved via user stylesheet, bookmarklet, extension, or application.</p>
</section>
<p>It is beneficial for users if authors use any locally available guidance for improving readability in the local language or writing system. If the user chooses to go beyond the metrics specified, any resulting loss of content or functionality is the user's responsibility.</p>

<section>
<h3 id="effects-not-allowing">Effects of Not Allowing for Spacing Override</h3>
<p>The following images show some types of failures when authors do not take into consideration that users may override spacing to the metrics specified in this Success Criterion.</p>
<section>
<h4 id="cutoff">Text Cut Off</h4>
<p>The bottom portion of the words &quot;Your Needs&quot; is cut off in a heading making that text unreadable in Figure 1. It should read &quot;We Provide a Mobile Application Service to Meet Your Needs.&quot;</p>
<figure id="figure-text-cut">
<figcaption>Vertical text cut off is a failure.</figcaption>
<img src="img/spacing_cutoff_fail_vertical.png" alt="Heading text truncated vertically." width="420" height="190" />
</figure>
<p>In Figure 2 the last portion of text is cut off in 3 side-by-side headings. The 1st heading should read &quot;A cog in the wheel.&quot; But it reads &quot;A cog in the whe&quot;. Only half of the second &quot;e&quot; is visible and the letter &quot;l&quot; is completely missing. The 2nd heading should read &quot;A penny for your thoughts&quot;. But it reads &quot;A penny for your&quot;. The 3rd should read &quot;Back to the drawing board.&quot; But it reads &quot;Back to the drawi&quot;. </p>
<figure id="figure-horiz-text-cut">
<figcaption>Horizontal text cut off is a failure.</figcaption>
<img src="img/spacing_cutoff_fail_horizontal.png" alt="3 side-by-side headings with truncated text." width="509" height="184" />
</figure>
</section>
<section>
<h4 id="overlap">Text Overlap</h4>
<p>In Figure 3 the last 3 words &quot;Groups and Programs&quot; of the heading "Technologists Seeking Input from Groups and Programs" overlap the following sentence. That sentence should read, &quot;You are invited to share ideas and areas of interest related to the integration of technology from a group or program perspective.&quot; But the words &quot;You are invited to share ideas&quot; are obscured and unreadable.</p>
<figure id="figure-overlapping-text">
<figcaption>Overlapping text is a failure.</figcaption>
<img src="img/spacing_overlap_fail.png" alt="Heading text overlaps part of paragraph text." width="510" height="170" />
</figure>
</section>
</section>

<p>Further, this SC is not concerned with <em>how</em> users change the line height and spacing metrics. It does not require that content implement its own mechanisms to allow users to do this. It is not a failure of the content if a user agent or platform does not provide a way for users to do this. Content does not fail this SC if the method chosen by the user - for instance, the use of an extension or bookmarklet - fails to correctly set the line height and spacing text properties on the content (provided that the content is not actively and purposely preventing the properties from being added).</p>
<section>
<h4 id="applicability">Applicability</h4>
<p>If the markup-based technologies being used are capable of overriding text to the Success Criterion's metrics, then this SC is applicable. For instance Cascading Style Sheet/HTML technologies are quite able to allow for the specified spacing metrics. Plugin technologies would need to have a built-in ability to modify styles to the specified metrics. Currently, this SC does not apply to PDF as it is not implemented using markup.</p>
<p>Examples of text that are typically not affected by <a>style properties</a> and not expected to adapt are:</p>
<ul>
<li>Video captions embedded directly into the video frames and not provided as an associated caption file</li>
<li><a>Images of text</a></li>
</ul>
<p>For this SC, <a href="https://html.spec.whatwg.org/multipage/canvas.html#the-canvas-element">canvas</a> implementations of text are considered to be <a>images of text</a>.</p>
</section>
<section id="benefits">
<h2>Benefits</h2>
<ul>
<li>People with low vision who require increased space between lines, words, and letters are able to read text.</li>
<li>People with dyslexia may increase space between lines, words, and letters to increase reading speed.</li>
<li>Although not required by this SC, white space between blocks of text can help people with cognitive disabilities discern sections and call out boxes.</li>
</ul>
</section>
<section id="examples">
<h2>Examples</h2>
<p>When spacing is being overridden to the SC's metrics:</p>
<section>
<h4 id="ellipses">Use of ellipses</h4>
<p>There may be regions of a page where text containers cannot expand due to design constraints (such as a maximum width for the left navigation or table column headers). A common convention if text exceeds its space is to replace truncated text with an ellipsis. Where ellipses appear as a result of modifying text style properties, the page can still meet the Text Spacing requirements, so long as the content is still available. For example:</p>
<ul>
<li>Text fits within the bounds of its containing box without being cut off.</li>
<li>Text fits within the bounds of its containing box without overlapping other boxes.</li>
</ul>
<li>a mechanism is provided to reveal the truncated text on the page (for instance, the text appears on focus or on activation)</li>
<li>where the ellipsis is part of a section of content which includes a link, the truncated text is revealed on the linked page</li>
</ul>
<p>Where text is not truncated but it is when text is spaced, if there is no mechanism to show the truncated text, it fails this Success Criterion.</p>
</section>
</section>
<section>
<h3 id="userresp">User Responsibility</h3>
<p>The ability to read and derive meaning from the overridden spacing rests with the user. The user may choose to exceed the spacing adjustments in the SC. If the increased spacing causes loss of content or functionality, the user will adjust or return to the author’s original spacing or spacing within the bounds of the SC. Regardless, the user needs the flexibility to adjust spacing within the bounds set in the SC without loss of content or functionality. Such changes may be achieved via user stylesheet, bookmarklet, extension, or application.</p>
</section>

<section>
<h3 id="effects-not-allowing">Effects of Not Allowing for Spacing Override</h3>
<p>The following images show some types of failures when authors do not take into consideration that users may override spacing to the metrics specified in this Success Criterion.</p>
<section>
<h4 id="cutoff">Text Cut Off</h4>
<p>The bottom portion of the words &quot;Your Needs&quot; is cut off in a heading making that text unreadable in Figure 1. It should read &quot;We Provide a Mobile Application Service to Meet Your Needs.&quot;</p>
<figure id="figure-text-cut">
<figcaption>Vertical text cut off is a failure.</figcaption>
<img src="img/spacing_cutoff_fail_vertical.png" alt="Heading text truncated vertically." width="420" height="190" />
</figure>
<p>In Figure 2 the last portion of text is cut off in 3 side-by-side headings. The 1st heading should read &quot;A cog in the wheel.&quot; But it reads &quot;A cog in the whe&quot;. Only half of the second &quot;e&quot; is visible and the letter &quot;l&quot; is completely missing. The 2nd heading should read &quot;A penny for your thoughts&quot;. But it reads &quot;A penny for your&quot;. The 3rd should read &quot;Back to the drawing board.&quot; But it reads &quot;Back to the drawi&quot;. </p>
<figure id="figure-horiz-text-cut">
<figcaption>Horizontal text cut off is a failure.</figcaption>
<img src="img/spacing_cutoff_fail_horizontal.png" alt="3 side-by-side headings with truncated text." width="509" height="184" />
</figure>
</section>
<section id="resources">
<h2>Resources</h2>
<section>
<h3>Research</h3>
<p>The grounds for this SC are <a href="#resources">based on research</a>. The metrics chosen as measures are based on the <a href="http://journals.sagepub.com/doi/pdf/10.1177/0264619607075995">McLeish</a> study. She ran from .04 to .25 em tests. McLeish found an increasing curve in reading speed of actual materials up to .25, but it started to flatten at .20. Previous studies that reported no improvement started at .5em. Right at the flat point. <a href="https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2017Jun/0047.html">Wayne E. Dick, Ph.D. analyzed the McLeish study</a> and translated from points. Dr. Dick recommended the metrics that the Working Group adopted.</p>
<section>
<h4 id="lang">Languages and Scripts</h4>
<p>Roughly 480 different languages and scripts <a href="https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2018Feb/0001.html">have been tested</a>. Maximum spacing adjustments allowed by the SC were set on the following 3 pages:</p>
<ul>
<li><a href="http://www.geonames.de/languages.html">Languages in their own writing systems</a></li>
<li><a href="https://www.omniglot.com/language/names.htm">Online Encyclopedia of writing systems and languages &#8211; language names</a></li>
<li><a href="https://www.omniglot.com/language/phrases/index.htm">Universal Declaration of Human Rights (Article 1)</a></li>
</ul>
</section>
<section>
<h4 id="results">Results</h4>
<p id="langimpact">No adverse effects occurred. The following are the specific findings:</p>
<dl>
<dt>Character Spacing </dt>
<dd>Individual characters in words remained intact though they were spaced a bit further apart.</dd>
<dt>Word Spacing </dt>
<dd>Words were spaced farther apart. In languages that do not have words (e.g. Japanese) applying word spacing had no effect. This is expected.</dd>
<dt>Line Height</dt>
<dd>Changing line height did not separate diacritics from characters, nor did it adversely impact ascenders or descenders.</dd>
</dl>
<p>As previously discussed, the ability to read text with adjusted spacing is a user responsibility. This is true no matter the language. </p>
<p>The SC's exception addresses cases where a text style property is not used in a language or script. In such cases, authors are only required to ensure relevant properties do not break the layout.</p>
</section>
</section>
<section>
<h3>Other references</h3>
<ul>
<li>Allan, Kirkpatrick, Lawton Henry, Editors. (2017). <a href="https://www.w3.org/TR/low-vision-needs/#spacing">Accessibility Requirements for People with Low Vision (3.4 Spacing for Reading)</a>. World Wide Web Consortium.</li>
<li><a href="https://github.com/openstyles/stylus/graphs/contributors">Stylus Team</a> (2012). <a href="https://github.com/openstyles/stylus/blob/master/README.md">Stylus browser extension</a> (Firefox, Chrome, and Opera) (compatible with Userstyles.org material).</li>
<li>Campbell, Alastair. (2017). <a href="https://github.com/alastc/adaptation-scripts/blob/master/scripts/text-adaptation.js">Text Adaptation Bookmarklet</a>. GitHub.</li>
<li>Chung, Susana T. L. (2012). <a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3429790/">Dependence of Reading Speed on Letter Spacing in Central Vision Loss</a>. Optom Vis Sci.</li>
<li>Chung, Susana T. L. (2002). <a href="http://journals.sagepub.com/doi/pdf/10.1177/0264619607075995">The Effect of Letter Spacing on Reading Speed in Central and Peripheral Vision (PDF)</a>. IOVS ARVO Journals.</li>
<li>Mcleish, Eve. (2007). <a href="http://journals.sagepub.com/doi/pdf/10.1177/0264619607075995">A study of the effect of letter spacing on the reading speed of young readers with low vision (PDF)</a>. The British Journal of Visual Impairment 25.2: 133-43.</li>
<li>Rello, L., &amp; Baeza-Yates, R. A. (2017). <a href="https://link.springer.com/article/10.1007/s10209-015-0438-8"> How to present more readable text for people with dyslexia</a>. Universal Access in the Information Society, 16(1), 29-49.</li>
<li> Sjoblom, A.M., Eaton, E. and Stagg, S.D., (2016). <a href="http://onlinelibrary.wiley.com/doi/10.1111/bjep.12127/full">The effects of letter spacing and coloured overlays on reading speed and accuracy in adult dyslexia</a>. British Journal of Educational Psychology, 86(4), pp. 630-639). </li>
<li>Zorzi, Marco et, al. (2012). <a href="http://www.pnas.org/content/109/28/11455.full">Extra-large letter spacing improves reading in dyslexia</a>. Proceedings of the National Academy of Sciences.</li>
</ul>
</section>
<section>
<h4 id="overlap">Text Overlap</h4>
<p>In Figure 3 the last 3 words &quot;Groups and Programs&quot; of the heading "Technologists Seeking Input from Groups and Programs" overlap the following sentence. That sentence should read, &quot;You are invited to share ideas and areas of interest related to the integration of technology from a group or program perspective.&quot; But the words &quot;You are invited to share ideas&quot; are obscured and unreadable.</p>
<figure id="figure-overlapping-text">
<figcaption>Overlapping text is a failure.</figcaption>
<img src="img/spacing_overlap_fail.png" alt="Heading text overlaps part of paragraph text." width="510" height="170" />
</figure>
</section>
<section id="techniques">
<h2>Techniques</h2>
<section id="sufficient">
<h3>Sufficient</h3>
<ul>
<li><a href="../../techniques/CSS/C36">Allowing for Spacing Override (Draft)
</a>
</li>
<li><a href="../../techniques/CSS/C35">C35</a></li>
</ul>
</section>
<section id="advisory">
<h3>Advisory</h3>
<ul>
<li><a href="https://www.w3.org/WAI/WCAG21/Techniques/css/C8" class="css">C8: Using CSS letter-spacing to control spacing within a word</a></li>
<li><a href="https://www.w3.org/WAI/WCAG21/Techniques/css/C21" class="css">C21: Specifying line spacing in CSS</a></li>
<li><a href="https://www.w3.org/WAI/WCAG21/Techniques/css/C28" class="css">C28: Specifying the size of text containers using em units </a></li>
</ul>
</section>
<section id="failure">
<h3>Failure</h3>
<ul>
<li><a href="../../techniques/failures/F104"></a></li>
</ul>
</section>
</section>
</section>
<section id="benefits">
<h2>Benefits</h2>
<ul>
<li>People with low vision who require increased space between lines, words, and letters are able to read text.</li>
<li>People with dyslexia may increase space between lines, words, and letters to increase reading speed.</li>
<li>Although not required by this SC, white space between blocks of text can help people with cognitive disabilities discern sections and call out boxes.</li>
</ul>
</section>
<section id="examples">
<h2>Examples</h2>
<p>When spacing is being overridden to the SC's metrics:</p>
<ul>
<li>Text fits within the bounds of its containing box without being cut off.</li>
<li>Text fits within the bounds of its containing box without overlapping other boxes.</li>
</ul>
</section>
<section id="resources">
<h2>Resources</h2>
<section>
<h3>Research</h3>
<p>The grounds for this SC are <a href="#resources">based on research</a>. The metrics chosen as measures are based on the <a href="http://journals.sagepub.com/doi/pdf/10.1177/0264619607075995">McLeish</a> study. She ran from .04 to .25 em tests. McLeish found an increasing curve in reading speed of actual materials up to .25, but it started to flatten at .20. Previous studies that reported no improvement started at .5em. Right at the flat point. <a href="https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2017Jun/0047.html">Wayne E. Dick, Ph.D. analyzed the McLeish study</a> and translated from points. Dr. Dick recommended the metrics that the Working Group adopted.</p>
<section>
<h4 id="lang">Languages and Scripts</h4>
<p>Roughly 480 different languages and scripts <a href="https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2018Feb/0001.html">have been tested</a>. Maximum spacing adjustments allowed by the SC were set on the following 3 pages:</p>
<ul>
<li><a href="http://www.geonames.de/languages.html">Languages in their own writing systems</a></li>
<li><a href="https://www.omniglot.com/language/names.htm">Online Encyclopedia of writing systems and languages &#8211; language names</a></li>
<li><a href="https://www.omniglot.com/language/phrases/index.htm">Universal Declaration of Human Rights (Article 1)</a></li>
</ul>
</section>
<section>
<h4 id="results">Results</h4>
<p id="langimpact">No adverse effects occurred. The following are the specific findings:</p>
<dl>
<dt>Character Spacing </dt>
<dd>Individual characters in words remained intact though they were spaced a bit further apart.</dd>
<dt>Word Spacing </dt>
<dd>Words were spaced farther apart. In languages that do not have words (e.g. Japanese) applying word spacing had no effect. This is expected.</dd>
<dt>Line Height</dt>
<dd>Changing line height did not separate diacritics from characters, nor did it adversely impact ascenders or descenders.</dd>
</dl>
<p>As previously discussed, the ability to read text with adjusted spacing is a user responsibility. This is true no matter the language.</p>
<p>The SC's exception addresses cases where a text style property is not used in a language or script. In such cases, authors are only required to ensure relevant properties do not break the layout.</p>
</section>
</section>
<section>
<h3>Other references</h3>
<ul>
<li>Allan, Kirkpatrick, Lawton Henry, Editors. (2017). <a href="https://www.w3.org/TR/low-vision-needs/#spacing">Accessibility Requirements for People with Low Vision (3.4 Spacing for Reading)</a>. World Wide Web Consortium.</li>
<li><a href="https://github.com/openstyles/stylus/graphs/contributors">Stylus Team</a> (2012). <a href="https://github.com/openstyles/stylus/blob/master/README.md">Stylus browser extension</a> (Firefox, Chrome, and Opera) (compatible with Userstyles.org material).</li>
<li>Campbell, Alastair. (2017). <a href="https://github.com/alastc/adaptation-scripts/blob/master/scripts/text-adaptation.js">Text Adaptation Bookmarklet</a>. GitHub.</li>
<li>Chung, Susana T. L. (2012). <a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3429790/">Dependence of Reading Speed on Letter Spacing in Central Vision Loss</a>. Optom Vis Sci.</li>
<li>Chung, Susana T. L. (2002). <a href="http://journals.sagepub.com/doi/pdf/10.1177/0264619607075995">The Effect of Letter Spacing on Reading Speed in Central and Peripheral Vision (PDF)</a>. IOVS ARVO Journals.</li>
<li>Mcleish, Eve. (2007). <a href="http://journals.sagepub.com/doi/pdf/10.1177/0264619607075995">A study of the effect of letter spacing on the reading speed of young readers with low vision (PDF)</a>. The British Journal of Visual Impairment 25.2: 133-43.</li>
<li>Rello, L., &amp; Baeza-Yates, R. A. (2017). <a href="https://link.springer.com/article/10.1007/s10209-015-0438-8"> How to present more readable text for people with dyslexia</a>. Universal Access in the Information Society, 16(1), 29-49.</li>
<li> Sjoblom, A.M., Eaton, E. and Stagg, S.D., (2016). <a href="http://onlinelibrary.wiley.com/doi/10.1111/bjep.12127/full">The effects of letter spacing and coloured overlays on reading speed and accuracy in adult dyslexia</a>. British Journal of Educational Psychology, 86(4), pp. 630-639). </li>
<li>Zorzi, Marco et, al. (2012). <a href="http://www.pnas.org/content/109/28/11455.full">Extra-large letter spacing improves reading in dyslexia</a>. Proceedings of the National Academy of Sciences.</li>
</ul>
</section>
</section>
<section id="techniques">
<h2>Techniques</h2>
<section id="sufficient">
<h3>Sufficient</h3>
<ul>
<li><a href="../../techniques/CSS/C36">Allowing for Spacing Override (Draft)</a></li>
<li><a href="../../techniques/CSS/C35">C35</a></li>
</ul>
</section>
</body>
<section id="advisory">
<h3>Advisory</h3>
<ul>
<li><a href="https://www.w3.org/WAI/WCAG21/Techniques/css/C8" class="css">C8: Using CSS letter-spacing to control spacing within a word</a></li>
<li><a href="https://www.w3.org/WAI/WCAG21/Techniques/css/C21" class="css">C21: Specifying line spacing in CSS</a></li>
<li><a href="https://www.w3.org/WAI/WCAG21/Techniques/css/C28" class="css">C28: Specifying the size of text containers using em units</a></li>
</ul>
</section>
<section id="failure">
<h3>Failure</h3>
<ul>
<li><a href="../../techniques/failures/F104"></a></li>
</ul>
</section>
</section>
</body>
</html>

0 comments on commit 3a11fbd

Please sign in to comment.