CINXE.COM

<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head> <meta charset="utf-8"> <meta name="generator" content="ReSpec 35.2.2"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> <style> .issue-label{text-transform:initial} .warning>p:first-child{margin-top:0} .warning{padding:.5em;border-left-width:.5em;border-left-style:solid} span.warning{padding:.1em .5em .15em} .issue.closed span.issue-number{text-decoration:line-through} .issue.closed span.issue-number::after{content:" (Closed)";font-size:smaller} .warning{border-color:#f11;border-color:var(--warning-border,#f11);border-width:.2em;border-style:solid;background:#fbe9e9;background:var(--warning-bg,#fbe9e9);color:#000;color:var(--text,#000)} .warning-title:before{content:"⚠";font-size:1.3em;float:left;padding-right:.3em;margin-top:-.3em} li.task-list-item{list-style:none} input.task-list-item-checkbox{margin:0 .35em .25em -1.6em;vertical-align:middle} .issue a.respec-gh-label{padding:5px;margin:0 2px 0 2px;font-size:10px;text-transform:none;text-decoration:none;font-weight:700;border-radius:4px;position:relative;bottom:2px;border:none;display:inline-block} </style> <style> dfn{cursor:pointer} .dfn-panel{position:absolute;z-index:35;min-width:300px;max-width:500px;padding:.5em .75em;margin-top:.6em;font-family:"Helvetica Neue",sans-serif;font-size:small;background:#fff;background:var(--indextable-hover-bg,#fff);color:#000;color:var(--text,#000);box-shadow:0 1em 3em -.4em rgba(0,0,0,.3),0 0 1px 1px rgba(0,0,0,.05);box-shadow:0 1em 3em -.4em var(--tocsidebar-shadow,rgba(0,0,0,.3)),0 0 1px 1px var(--tocsidebar-shadow,rgba(0,0,0,.05));border-radius:2px} .dfn-panel:not(.docked)>.caret{position:absolute;top:-9px} .dfn-panel:not(.docked)>.caret::after,.dfn-panel:not(.docked)>.caret::before{content:"";position:absolute;border:10px solid transparent;border-top:0;border-bottom:10px solid #fff;border-bottom-color:var(--indextable-hover-bg,#fff);top:0} .dfn-panel:not(.docked)>.caret::before{border-bottom:9px solid #a2a9b1;border-bottom-color:var(--indextable-hover-bg,#a2a9b1)} .dfn-panel *{margin:0} .dfn-panel b{display:block;color:#000;color:var(--text,#000);margin-top:.25em} .dfn-panel ul a[href]{color:#333;color:var(--text,#333)} .dfn-panel>div{display:flex} .dfn-panel a.self-link{font-weight:700;margin-right:auto} .dfn-panel .marker{padding:.1em;margin-left:.5em;border-radius:.2em;text-align:center;white-space:nowrap;font-size:90%;color:#040b1c} .dfn-panel .marker.dfn-exported{background:#d1edfd;box-shadow:0 0 0 .125em #1ca5f940} .dfn-panel .marker.idl-block{background:#8ccbf2;box-shadow:0 0 0 .125em #0670b161} .dfn-panel a:not(:hover){text-decoration:none!important;border-bottom:none!important} .dfn-panel a[href]:hover{border-bottom-width:1px} .dfn-panel ul{padding:0} .dfn-panel li{margin-left:1em} .dfn-panel.docked{position:fixed;left:.5em;top:unset;bottom:2em;margin:0 auto;max-width:calc(100vw - .75em * 2 - .5em - .2em * 2);max-height:30vh;overflow:auto} </style> <title>Collaboration Tools Accessibility User Requirements</title> <style id="respec-mainstyle"> @keyframes pop{ 0%{transform:scale(1,1)} 25%{transform:scale(1.25,1.25);opacity:.75} 100%{transform:scale(1,1)} } a.internalDFN{color:inherit;border-bottom:1px solid #99c;text-decoration:none} a.externalDFN{color:inherit;border-bottom:1px dotted #ccc;text-decoration:none} a.bibref{text-decoration:none} .respec-offending-element:target{animation:pop .25s ease-in-out 0s 1} .respec-offending-element,a[href].respec-offending-element{text-decoration:red wavy underline} @supports not (text-decoration:red wavy underline){ .respec-offending-element:not(pre){display:inline-block} .respec-offending-element{background:url(data:image/gif;base64,R0lGODdhBAADAPEAANv///8AAP///wAAACwAAAAABAADAEACBZQjmIAFADs=) bottom repeat-x} } #references :target{background:#eaf3ff;animation:pop .4s ease-in-out 0s 1} cite .bibref{font-style:normal} a[href].orcid{padding-left:4px;padding-right:4px} a[href].orcid>svg{margin-bottom:-2px} ol.tof,ul.tof{list-style:none outside none} .caption{margin-top:.5em;font-style:italic} #issue-summary>ul{column-count:2} #issue-summary li{list-style:none;display:inline-block} details.respec-tests-details{margin-left:1em;display:inline-block;vertical-align:top} details.respec-tests-details>*{padding-right:2em} details.respec-tests-details[open]{z-index:999999;position:absolute;border:thin solid #cad3e2;border-radius:.3em;background-color:#fff;padding-bottom:.5em} details.respec-tests-details[open]>summary{border-bottom:thin solid #cad3e2;padding-left:1em;margin-bottom:1em;line-height:2em} details.respec-tests-details>ul{width:100%;margin-top:-.3em} details.respec-tests-details>li{padding-left:1em} .self-link:hover{opacity:1;text-decoration:none;background-color:transparent} aside.example .marker>a.self-link{color:inherit} .header-wrapper{display:flex;align-items:baseline} :is(h2,h3,h4,h5,h6):not(#toc>h2,#abstract>h2,#sotd>h2,.head>h2){position:relative;left:-.5em} :is(h2,h3,h4,h5,h6):not(#toch2)+a.self-link{color:inherit;order:-1;position:relative;left:-1.1em;font-size:1rem;opacity:.5} :is(h2,h3,h4,h5,h6)+a.self-link::before{content:"§";text-decoration:none;color:var(--heading-text)} :is(h2,h3)+a.self-link{top:-.2em} :is(h4,h5,h6)+a.self-link::before{color:#000} @media (max-width:767px){ dd{margin-left:0} } @media print{ .removeOnSave{display:none} } </style> <meta name="color-scheme" content="light"> <meta name="description" content="This document outlines various accessibility-related user needs and requirements for both synchronous and asynchronous web-based collaboration tools based on various collaborative engagement scenarios. These tools typically include one or more specific collaborative features such as content editing by multiple authors, support for comments annotations, and revision control in real-time synchronous sessions, or asynchronously. Asynchronous tools are more commonly known as revision control systems rather than collaboration tools though their functionality is otherwise very similar. The Cloud-based office application suites from Google and Microsoft are well-known examples of synchronous, real-time collaboration tools, though they also support asynchronous collaboration. Web tools built on git are well-known examples of asynchronous collaboration tools."> <link rel="canonical" href="https://www.w3.org/TR/ctaur/"> <style> var{position:relative;cursor:pointer} var[data-type]::after,var[data-type]::before{position:absolute;left:50%;top:-6px;opacity:0;transition:opacity .4s;pointer-events:none} var[data-type]::before{content:"";transform:translateX(-50%);border-width:4px 6px 0 6px;border-style:solid;border-color:transparent;border-top-color:#222} var[data-type]::after{content:attr(data-type);transform:translateX(-50%) translateY(-100%);background:#222;text-align:center;font-family:"Dank Mono","Fira Code",monospace;font-style:normal;padding:6px;border-radius:3px;color:#daca88;text-indent:0;font-weight:400} var[data-type]:hover::after,var[data-type]:hover::before{opacity:1} </style> <script id="initialUserConfig" type="application/json">{ "trace": true, "useExperimentalStyles": true, "doRDFa": "1.1", "includePermalinks": true, "permalinkEdge": true, "permalinkHide": false, "noRecTrack": true, "tocIntroductory": true, "lint": { "no-unused-dfns": false }, "specStatus": "NOTE", "diffTool": "http://www.aptest.com/standards/htmldiff/htmldiff.pl", "shortName": "ctaur", "copyrightStart": "2022", "license": "w3c-software-doc", "editors": [ { "name": "Jason White", "url": "https://jasonjgw.net/", "company": "Invited expert", "w3cid": 74028 }, { "name": "Janina Sajka", "url": "http://rednote.net/", "company": "Invited expert", "w3cid": 33688 }, { "name": "Scott Hollier", "company": "Centre for Accessibility Australia", "url": "https://www.accessibility.org.au/", "w3cid": 43274 } ], "authors": [ { "name": "Jason White", "url": "https://jasonjgw.net/", "company": "Invited expert", "w3cid": 74028 }, { "name": "Janina Sajka", "url": "http://rednote.net/", "company": "Invited expert", "w3cid": 33688 }, { "name": "Scott Hollier", "company": "Centre for Accessibility Australia", "url": "https://www.accessibility.org.au/", "w3cid": 43274 }, { "name": "Lisa Seeman-Horwitz", "url": "http://athena-ict.com", "company": "Invited expert", "w3cid": 16320 } ], "group": "apa", "github": "w3c/ctaur", "maxTocLevel": 4, "publishISODate": "2025-01-21T00:00:00.000Z", "generatedSubtitle": "W3C Group Note 21 January 2025" }</script> <link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/2021/W3C-NOTE"></head> <body class="h-entry informative" data-new-gr-c-s-check-loaded="14.1217.0" data-gr-ext-installed=""><div class="head"> <p class="logos"><a class="logo" href="https://www.w3.org/"><img crossorigin="" alt="W3C" height="48" src="https://www.w3.org/StyleSheets/TR/2021/logos/W3C" width="72"> </a></p> <h1 id="title" class="title">Collaboration Tools Accessibility User Requirements</h1> <p id="w3c-state"><a href="https://www.w3.org/standards/types#NOTE">W3C Group Note</a> <time class="dt-published" datetime="2025-01-21">21 January 2025</time></p> <details open=""> <summary>More details about this document</summary> <dl> <dt>This version:</dt><dd> <a class="u-url" href="https://www.w3.org/TR/2025/NOTE-ctaur-20250121/">https://www.w3.org/TR/2025/NOTE-ctaur-20250121/</a> </dd> <dt>Latest published version:</dt><dd> <a href="https://www.w3.org/TR/ctaur/">https://www.w3.org/TR/ctaur/</a> </dd> <dt>Latest editor's draft:</dt><dd><a href="https://w3c.github.io/ctaur/">https://w3c.github.io/ctaur/</a></dd> <dt>History:</dt><dd> <a href="https://www.w3.org/standards/history/ctaur/">https://www.w3.org/standards/history/ctaur/</a> </dd><dd> <a href="https://github.com/w3c/ctaur/commits/">Commit history</a> </dd> <dt>Editors:</dt><dd class="editor p-author h-card vcard" data-editor-id="74028"> <a class="u-url url p-name fn" href="https://jasonjgw.net/">Jason White</a> (<span class="p-org org h-org">Invited expert</span>) </dd><dd class="editor p-author h-card vcard" data-editor-id="33688"> <a class="u-url url p-name fn" href="http://rednote.net/">Janina Sajka</a> (<span class="p-org org h-org">Invited expert</span>) </dd><dd class="editor p-author h-card vcard" data-editor-id="43274"> <a class="u-url url p-name fn" href="https://www.accessibility.org.au/">Scott Hollier</a> (<span class="p-org org h-org">Centre for Accessibility Australia</span>) </dd> <dt>Authors:</dt><dd class="editor p-author h-card vcard" data-editor-id="74028"> <a class="u-url url p-name fn" href="https://jasonjgw.net/">Jason White</a> (<span class="p-org org h-org">Invited expert</span>) </dd><dd class="editor p-author h-card vcard" data-editor-id="33688"> <a class="u-url url p-name fn" href="http://rednote.net/">Janina Sajka</a> (<span class="p-org org h-org">Invited expert</span>) </dd><dd class="editor p-author h-card vcard" data-editor-id="43274"> <a class="u-url url p-name fn" href="https://www.accessibility.org.au/">Scott Hollier</a> (<span class="p-org org h-org">Centre for Accessibility Australia</span>) </dd><dd class="editor p-author h-card vcard" data-editor-id="16320"> <a class="u-url url p-name fn" href="http://athena-ict.com">Lisa Seeman-Horwitz</a> (<span class="p-org org h-org">Invited expert</span>) </dd> <dt>Feedback:</dt><dd> <a href="https://github.com/w3c/ctaur/">GitHub w3c/ctaur</a> - (<a href="https://github.com/w3c/ctaur/pulls/">pull requests</a>, <a href="https://github.com/w3c/ctaur/issues/new/choose">new issue</a>, <a href="https://github.com/w3c/ctaur/issues/">open issues</a>) </dd> <dd><span>email: <a href="mailto:public-rqtf@w3.org?subject=%5BCTAUR%5D%20YOUR%20TOPIC%20HERE">public-rqtf@w3.org</a> with subject line “<kbd>[CTAUR] <i data-lt="">… message topic …</i></kbd>” (<a href="https://lists.w3.org/Archives/Public/public-rqtf/" rel="discussion">archives</a>)</span> </dd> </dl> </details> <p class="copyright"> <a href="https://www.w3.org/policies/#copyright">Copyright</a> © 2022-2025 <a href="https://www.w3.org/">World Wide Web Consortium</a>. <abbr title="World Wide Web Consortium">W3C</abbr><sup>®</sup> <a href="https://www.w3.org/policies/#Legal_Disclaimer">liability</a>, <a href="https://www.w3.org/policies/#W3C_Trademarks">trademark</a> and <a rel="license" href="https://www.w3.org/copyright/software-license-2023/" title="W3C Software and Document Notice and License">permissive document license</a> rules apply. </p> <hr title="Separator for header"> </div> <section id="abstract" class="introductory"><h2>Abstract</h2> <p>This document outlines various accessibility-related user needs and requirements for both synchronous and asynchronous web-based collaboration tools based on various collaborative engagement scenarios. These tools typically include one or more specific collaborative features such as content editing by multiple authors, support for comments annotations, and revision control in real-time synchronous sessions, or asynchronously. Asynchronous tools are more commonly known as revision control systems rather than collaboration tools though their functionality is otherwise very similar. The Cloud-based office application suites from Google and Microsoft are well-known examples of synchronous, real-time collaboration tools, though they also support asynchronous collaboration. Web tools built on git are well-known examples of asynchronous collaboration tools.</p> <p>The accessibility user needs and requirements described in this document may be implemented in the collaboration tool itself, or in an assistive technology application such as a screen reader or screen magnifier. Widely used desktop applications such as word processors and spread sheets also commonly support collaboration features. We take a holistic approach to give foremost priority to the user's perspective, leading to the identification of features and solutions that may be implemented by different components of the software stack involved in performing a collaborative task.</p> <p>Although the user needs and requirements identified in this document <em>are non-normative</em>, they may influence the development of future accessibility guidelines, normative technical specifications, or features of collaboration tools and assistive technologies. They are relevant to software developers who contribute to the collaborative experience.</p> </section> <section id="sotd" class="introductory"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at https://www.w3.org/TR/.</em></p> <p>As a Working Group Note this content is stable, and the Working Group does not plan to make further changes. Should the need arise, however, the document could be updated. Comments received on this document will help the Working Group to decide if updates are needed, or will be taken into account should a republication be planned. </p> <p>To comment, <a href="https://github.com/w3c/ctaur/issues/new">file an issue in the <abbr title="World Wide Web Consortium">W3C</abbr> ctaur GitHub repository</a>. If this is not feasible, send email to <a href="mailto:public-rqtf@w3.org?subject=Comment%20on%20CTAUR">public-rqtf@w3.org</a> (<a href="https://lists.w3.org/Archives/Public/public-rqtf/">comment archive</a>). In-progress updates to the document may be viewed in the <a href="https://w3c.github.io/ctaur/">publicly visible editors' draft</a>.</p> <p> This document was published by the <a href="https://www.w3.org/groups/wg/apa">Accessible Platform Architectures Working Group</a> as a Group Note using the <a href="https://www.w3.org/policies/process/20231103/#recs-and-notes">Note track</a>. </p><p>This Group Note is endorsed by the <a href="https://www.w3.org/groups/wg/apa">Accessible Platform Architectures Working Group</a>, but is not endorsed by <abbr title="World Wide Web Consortium">W3C</abbr> itself nor its Members. </p><p> 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><p data-deliverer="83907"> The <a href="https://www.w3.org/policies/patent-policy/"><abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a> does not carry any licensing requirements or commitments on this document. </p><p> This document is governed by the <a id="w3c_process_revision" href="https://www.w3.org/policies/process/20231103/">03 November 2023 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>. </p></section><nav id="toc"><h2 class="introductory" id="table-of-contents">Table of Contents</h2><ol class="toc"><li class="tocline"><a class="tocxref" href="#abstract">Abstract</a></li><li class="tocline"><a class="tocxref" href="#sotd">Status of This Document</a></li><li class="tocline"><a class="tocxref" href="#intro"><bdi class="secno">1. </bdi>Introduction</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#collaboration-tools"><bdi class="secno">1.1 </bdi>What are collaboration tools?</a></li><li class="tocline"><a class="tocxref" href="#distinctive-features"><bdi class="secno">1.2 </bdi>Our scope: distinctive features of collaboration tools</a></li><li class="tocline"><a class="tocxref" href="#need-definition"><bdi class="secno">1.3 </bdi>Defining user needs</a></li><li class="tocline"><a class="tocxref" href="#collab-a11y"><bdi class="secno">1.4 </bdi>Collaboration tools and accessibility</a></li><li class="tocline"><a class="tocxref" href="#social"><bdi class="secno">1.5 </bdi>Social Considerations</a></li><li class="tocline"><a class="tocxref" href="#scope"><bdi class="secno">1.6 </bdi>Scope and applicability of this document</a></li></ol></li><li class="tocline"><a class="tocxref" href="#synchronous"><bdi class="secno">2. </bdi>Real-time Co-editing</a></li><li class="tocline"><a class="tocxref" href="#annotations"><bdi class="secno">3. </bdi>Annotations</a></li><li class="tocline"><a class="tocxref" href="#version-control-features"><bdi class="secno">4. </bdi>Version control features</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#version-control-changes"><bdi class="secno">4.1 </bdi>Suggested changes</a></li><li class="tocline"><a class="tocxref" href="#diff"><bdi class="secno">4.2 </bdi>Presenting differences between revisions</a></li><li class="tocline"><a class="tocxref" href="#summation"><bdi class="secno">4.3 </bdi>Summarizations</a></li></ol></li><li class="tocline"><a class="tocxref" href="#notify"><bdi class="secno">5. </bdi>Notifications and Messages</a></li><li class="tocline"><a class="tocxref" href="#access-control"><bdi class="secno">6. </bdi>Access Controls</a></li><li class="tocline"><a class="tocxref" href="#conventions"><bdi class="secno">7. </bdi>General Guidance on Implementing Accessibility Features of Collaborative Environments</a></li><li class="tocline"><a class="tocxref" href="#acknowledgments"><bdi class="secno">A. </bdi>Acknowledgments</a></li><li class="tocline"><a class="tocxref" href="#references"><bdi class="secno">B. </bdi>References</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#informative-references"><bdi class="secno">B.1 </bdi>Informative references</a></li></ol></li></ol></nav> <section id="intro"><div class="header-wrapper"><h2 id="x1-introduction"><bdi class="secno">1. </bdi>Introduction</h2><a class="self-link" href="#intro" aria-label="Permalink for Section 1."></a></div> <section id="collaboration-tools"><div class="header-wrapper"><h3 id="x1-1-what-are-collaboration-tools"><bdi class="secno">1.1 </bdi>What are collaboration tools?</h3><a class="self-link" href="#collaboration-tools" aria-label="Permalink for Section 1.1"></a></div> <p>For the purposes of this document, a <dfn id="dfn-collaboration-tool" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">collaboration tool</dfn> is any software that supports features designed to facilitate the interactive creation, editing or annotation of content by multiple contributors, whether working in simultaneous collaboration or asynchronously. Examples of collaboration tools include</p> <ul> <li>A Web-based text editor or word processor that enables multiple authors to edit content simultaneously while discussing their edits during a Real Time Communications (<abbr title="Real Time Communications">RTC</abbr>) teleconference, with each contributor's changes being integrated into the resulting text and propagated in real time to the collaborators.</li> <li>A Web-based text editor or word processor that enables multiple authors to edit content asynchronously over many days and week, with each contributor's changes being integrated into the resulting text and propagated on next load to the collaborators.</li><li>A tool that enables Web pages to be annotated with comments that are automatically made available to other users of the annotation service who access the same pages with suitable software. The software may be included in a user agent, or it may be supplied as an extension.</li> <li>An Integrated Development Environment (<abbr title="Integrated development Environment">IDE</abbr>) that supports the collaborative editing of program source code in real time or asynchronously.</li> <li>A wiki that supports version control, for example by enabling authors to revert to prior versions of a page or to view the differences between two versions.</li> <li>A midi or audio editing application that allows real-time synchronous or asynchronous audio content editing. Collaborators hear edited content on demand during a teleconference editing session or on content refresh when editing asynchronously.</li> </ul> </section> <section id="distinctive-features"><div class="header-wrapper"><h3 id="x1-2-our-scope-distinctive-features-of-collaboration-tools"><bdi class="secno">1.2 </bdi>Our scope: distinctive features of collaboration tools</h3><a class="self-link" href="#distinctive-features" aria-label="Permalink for Section 1.2"></a></div> <p>This document focuses on features unique to collaboration tools, rather than features which they share with other Web applications. Most especially this document avoids discussion of features applicable to software in general. However, any software that provides one or more of the features enumerated here may benefit from the user needs and corresponding requirements elaborated in the sections that follow.</p> <p>The distinctive capabilities of collaboration tools are illustrated by the examples described in the section: <a href="#collaboration-tools" class="sec-ref"><bdi class="secno">1.1 </bdi>What are collaboration tools?</a>. It is important to consider how these features are manifested in the tool's user interface. From this perspective, the distinguishing features may be described as follows.</p> <dl> <dt>Real-time and asynchronous co-editing</dt> <dd>A feature enabling multiple authors to edit the same content simultaneously or over days, weeks, months, and years. In synchronous co-editing, the changes introduced by different authors in real-time are combined almost immediately, using algorithms such as operational transformation [<cite><a class="bibref" data-link-type="biblio" href="#bib-concurrency-control" title="Concurrency control in groupware systems">concurrency-control</a></cite>]. The combined changes are then made immediately visible in all of the participating authors' editing sessions. The effect is that each author may perceive in real time <ul> <li>Edits proposed by collaborators,</li> <li>The location of other editors' focus within content.</li> </ul> Asynchronous edits, on the other hand, are made visible on document reload.</dd> <dt>Annotation of content with comments</dt> <dd>Some tools enable users to associate comments with parts of the content that is being read or edited. In systems such as word processors, replying to comments is supported, allowing threads of discussion to be associated with parts of a document.</dd> <dt>Comparing revisions</dt> <dd>Some systems can display the differences between revisions of content for purposes of comparison.</dd> <dt>Suggested changes</dt> <dd>Some word processors can show changes (insertions, deletions, and formatting-related modifications) made by collaborators, which an editor can choose to accept or reject. These revisions are sometimes referred to as <dfn id="dfn-suggested-changes" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">suggested changes</dfn> or <dfn id="dfn-tracked-changes" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">tracked changes</dfn>. Each change may be accompanied by metadata, for example the identity of the author who made the change, and a time stamp.</dd> <dt>Access controls</dt> <dd>Some collaborative environments support <em>access controls</em>, allowing restrictions to be imposed on modification of part or all of the content. Permission to modify content may be granted on a granular basis to specific individuals or to groups of users. For example, in a collaborative tool for creating fillable forms, some users may only be allowed to change the values of input fields (i.e., to complete a form), whereas others may be free to edit any aspect of the document, including the addition, deletion, and rearrangement of form fields.</dd> </dl> <p>Collaboration tools differ widely in the nature of content that may be edited. They also differ widely in the user interfaces presented to users. For example:</p> <ul> <li>Word processors typically provide a <a href="https://en.wikipedia.org/wiki/WYSIWYG"><q>what you see is what you get</q> (<abbr title="what you see is what you get">WYSIWYG</abbr>)</a> interface based on a rendered view of the content.</li> <li>Editors designed for source code or markup language text development do not provide a rendered view. In these applications, indentation and syntax highlighting may be the only visual cues provided to the structure of the code or markup available in the editing environment.</li> <li>In collaborative video editors, candidate video renditions may be played in side by side windows for purposes of comparison and editing decisioning.</li> <li>By their very nature, audio alternatives presented in music or sound editing environments must be played sequentially, and their distinctions remembered by the user in the comparison and decisioning process.</li> </ul> <p>As the preceding cases suggest, collaboration tools are not restricted by the kind of content that may be edited. Thus, tools that support editing of static images, mathematical notation, or other content types are also within the scope of this document. However, only collaboration-related aspects of any content editing environment are addressed here. Accessibility issues particular to creating and editing various types of content are not considered in this document.</p> <p>Nevertheless it is important that collaborative tools support the full range of editing functions associated with making web content accessible. Among others this would include the ability to add headings, provide alternative text for images, and add captions to videos.</p> <p>Some collaboration tools support accessibility by mapping unique keyboard commands. Some also organize their feature options in unique menus or uniquely located menus. We prefer collaboration tools that utilize standard menu organization and typical keyboard commands now well-known to users from the stand-alone desktop environment. Standard controls require far less learning from the user, whereas specific accessibility modes with custom keyboard commands and with menus that shift their location on screen pose significantly steep learning challenges to most users with disabilities, not just users with cognitive and learning disabilities.</p> </section> <section id="need-definition"><div class="header-wrapper"><h3 id="x1-3-defining-user-needs"><bdi class="secno">1.3 </bdi>Defining user needs</h3><a class="self-link" href="#need-definition" aria-label="Permalink for Section 1.3"></a></div> <p>Specific user needs are frequently defined both by task required to achieve a particular goal and also by environmental conditions. Context matters. For example, the cognitive demands imposed by interacting with the collaboration-related features of an application depend not only on the needs and capabilities of the user, including the possible presence of assistive technology, but also on the context. A collaborative task that the user can perform independently while working alone in a distraction-free environment may quickly become cognitively burdensome when performed during a working teleconference session. Working with comments and suggested changes becomes more cognitively demanding when other authors are simultaneously editing the same content, and the user needs to be aware of their activities (e.g., to avoid introducing conflicting changes) while still performing the editing task. The use of different input types and methods, such as speech input or switch-based input, can significantly affect the amount of time required to enter and edit text, as well as the user's ability to respond to potentially disruptive changes introduced by collaborators.</p> </section> <section id="collab-a11y"><div class="header-wrapper"><h3 id="x1-4-collaboration-tools-and-accessibility"><bdi class="secno">1.4 </bdi>Collaboration tools and accessibility</h3><a class="self-link" href="#collab-a11y" aria-label="Permalink for Section 1.4"></a></div> <p>By following established guidance, notably that of <cite>Web Content Accessibility Guidelines (WCAG)</cite> [<cite><a class="bibref" data-link-type="biblio" href="#bib-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">wcag22</a></cite>], designers of collaboration tools can help ensure that their user interfaces are <em>perceivable</em> to and <em>operable</em> by a wide range of users with disabilities. Following the Guidelines also enables user interfaces to be more <em>understandable</em>, and to be <em>robust</em> in their support for a range of user agents and assistive technologies. In addition, broadly applicable guidance on improving accessibility for people with cognitive and learning disabilities has been published in [<cite><a class="bibref" data-link-type="biblio" href="#bib-coga-usable" title="Making Content Usable for People with Cognitive and Learning Disabilities">coga-usable</a></cite>]. However, implementing current guidelines and suggested practices is not sufficient by itself to ensure that the user interface of a collaboration tool can be understood and used efficiently by people with disabilities. Thus, conforming to WCAG may well be insufficient for collaborative environments. For example WCAG does not inform automated interface simplification — a general web accessibility requirement being considered in APA's <a href="https://www.w3.org/WAI/APA/task-forces/adapt/">WAI-Adapt Task Force</a>.</p> <p>The collaboration features of these tools are necessarily complex. This can impose significant cognitive demands on many users, not only users with specialized accessibility requirements. This is especially true for users of screen readers, screen magnification, and color contrast assistive technologies, as well as for persons living with various cognitive and learning disabilities. For this reason, the unique cognitive demands established by collaborative content creation applications can impose barriers to access which are addressable, in part, by making appropriate software design and implementation choices. Additional control of cognitive demands can be achieved by using the application and any assistive technologies appropriately in a collaborative setting, and by ensuring that the social context in which the collaboration occurs supports participation by contributors with disabilities (see section <a href="#social" class="sec-ref"><bdi class="secno">1.5 </bdi>Social Considerations</a>).</p> <p>Many users cannot track updates on multiple locations simultaneously, rather, they must view and comprehend the interactive elements of the application's features sequentially, for example in speech or braille for screen reader users. A screen reader or magnifier used in a collaborative application may well present suggested changes and comments in one section of the screen while the user is reading a document in a word processor. The user may also be expected to be communicating verbally with fellow collaborators (e.g., in an in-person or <abbr title="Real Time Communications">RTC</abbr> meeting) while undertaking editing tasks or comparing multiple revisions of content. Moreover, in applications supporting real-time collaborative editing, incoming changes made by other contributors may alter the content that the user is reading or editing in real time. These cognitive demands can be exacerbated when one is working with an unfamiliar user interface such as a rarely used <abbr title="Real Time Communications">RTC</abbr> client (See our <abbr title="Real Time Communications">RTC</abbr> Accessibility User Requirements [<cite><a class="bibref" data-link-type="biblio" href="#bib-raur" title="RTC Accessibility User Requirements">RAUR</a></cite>] publication).</p> <p>Due to the cognitive demands created by collaboration tools in the practical and social contexts in which they are used, strategies for improving accessibility are desirable that extend beyond current <abbr title="World Wide Web Consortium">W3C</abbr> guidance. Thus when we talk about collaborative tools we must consider accessibility burdens imposed by their associated complexity. In truth, collaborative tools are necessarily complex interfaces for all users, and not only persons with various disabilities. The salient point here is that a failure to design to accomodate persons with disabilities appropriately will inevitably prevent their participation in collaborative work. What constitutes challenging complexity for most users will inevitably become an insurmountable barrier for some persons with disabilities.</p> <p>A fairly common accessibility failure is the use of arbitrary color to flag edits put forth by different collaborators. However, identifying collaborators only by colorization violates WCAG Success Criterion 1.4.1 as described below in <a href="#version-control-changes">User Need 11</a>.</p> </section> <section id="social"><div class="header-wrapper"><h3 id="x1-5-social-considerations"><bdi class="secno">1.5 </bdi>Social Considerations</h3><a class="self-link" href="#social" aria-label="Permalink for Section 1.5"></a></div> <p>Collaborative tools should support all identified accessibility features in order to provide comprehensive accessibility. However, it is unlikely all features will be needed by any individual collaborative team effort. We assume persons with disabilities are brought into collaborative teams because of the contributions they are expected to make in the project. Teams are encouraged to focus on accommodating the specific accessibility needs of participating team members in order to operate most efficiently and productively.</p> </section> <section id="scope"><div class="header-wrapper"><h3 id="x1-6-scope-and-applicability-of-this-document"><bdi class="secno">1.6 </bdi>Scope and applicability of this document</h3><a class="self-link" href="#scope" aria-label="Permalink for Section 1.6"></a></div> <p>Accessibility-related guidance provided in this document is applicable to a wide variety of tools. No unnecessary restriction is placed on the types of Web-based software to which it may reasonably be applied.</p> <p>If a tool implements one or more of the distinctive features described in section <a href="#distinctive-features" class="sec-ref"><bdi class="secno">1.2 </bdi>Our scope: distinctive features of collaboration tools</a>, then the guidance in this document which addresses each such supported feature is relevant and applicable to the tool. Thus, the scope of the document includes any tool implemented using Web technologies that implements at least one of the distinctive features for which guidance is offered in the sections that follow.</p> <p>For example, an annotation tool supporting the association of shared comments with selected text in Web pages would offer only a single feature described in this document. For this reason, only section <a href="#annotations" class="sec-ref"><bdi class="secno">3. </bdi>Annotations</a> would be relevant to the tool.</p> </section> </section> <section id="synchronous"><div class="header-wrapper"><h2 id="x2-real-time-co-editing"><bdi class="secno">2. </bdi>Real-time Co-editing</h2><a class="self-link" href="#synchronous" aria-label="Permalink for Section 2."></a></div> <ul> <li><strong>User Need 1:</strong> Users need to be able to discover the presence of collaborators who are reading or editing the content.</li> <li><strong>REQ 1:</strong> Provide a mode of operation in which <em>status messages</em> alert the user whenever a collaborator opens or closes an interactive session involving the same content that the user is accessing (e.g., the same document).</li> </ul> <div class="note" role="note" id="issue-container-generatedID"><div role="heading" class="note-title marker" id="h-note" aria-level="3"><span>Note</span></div><p class="">WCAG requires that status messages be made available to assistive technologies. See <cite>Web Content Accessibility Guidelines (WCAG) 2.2</cite> [<cite><a class="bibref" data-link-type="biblio" href="#bib-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">wcag22</a></cite>], success criterion 4.1.3, and the associated definition of <em>status message</em>.</p></div> <ul> <li><strong>User Need 2:</strong> An assistive technology user needs to be informed in real time of changes to the content being made by collaborators.</li> <li><strong>REQ 2:</strong> Provide a mode of operation in which status messages inform the assistive technology user of insertions, deletions, or formatting-related changes made by collaborators as they occur. Limiting these notifications to a content span currently focused by the user is also an advisable option.</li> <li><strong>User Need 3:</strong> Users with learning or cognitive disabilities and assistive technology users need the ability to read or edit without being distracted or overwhelmed by status messages.</li> <li><strong>REQ 3:</strong> Provide a mode of operation in which status messages informing the user of the presence or activities of collaborators are suppressed. This may be achieved by allowing the user selectively to enable and disable specific types of status messages, messages relating to a specific span of content, or all such messages.</li> <li><strong>User Need 4:</strong> An assistive technology user needs the ability to track changes introduced by a specific collaborator as they are made.</li> <li><strong>REQ 4:</strong> Provide a function that moves and tracks user's focus to the location where a specific collaborator is editing. If there are multiple active collaborators, then multiple such commands, or a menu of active content editors, should be available.</li> <li><strong>User Need 5:</strong> Users with vision, cognitive, or physical disabilities need to be able to edit content without the distraction of contemperaneous edits being introduced by other collaborators.</li> <li><strong>REQ 5A:</strong> Provide a mode of operation in which changes made by collaborators are not displayed while any individual collaborator is editing and include some notification semaphore to indicate at least one collaborator is editing, or</li> <li><strong>REQ 5B:</strong> Provide a mode of operation in which the component of the content that the user is editing (e.g., the paragraph, section, semantic unit of source code, or graphical object) can only be changed by one collaborator at a time, preventing others from making simultaneous modifications to the same component and flag this status to all collaborators while the lock is active.</li> </ul> </section> <section id="annotations"><div class="header-wrapper"><h2 id="x3-annotations"><bdi class="secno">3. </bdi>Annotations</h2><a class="self-link" href="#annotations" aria-label="Permalink for Section 3."></a></div> <ul> <li><strong>User Need 6:</strong> An assistive technology user needs to be informed of the presence of annotations along with the specific part of the content being annotated, such as words, sentences, or paragraphs. This also applies to lines of code in a software development project.</li> <li><strong>REQ 6:</strong> Ensure that information about annotations is conveyed to assistive technologies, together with the boundaries of the text to which the annotation applies, along with any metadata associated with the annotation and any comment text.</li> </ul> <div class="note" role="note" id="issue-container-generatedID-0"><div role="heading" class="note-title marker" id="h-note-0" aria-level="3"><span>Note</span></div><p class="">See <cite>Web Content Accessibility Guidelines (WCAG) 2.2</cite> [<cite><a class="bibref" data-link-type="biblio" href="#bib-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">wcag22</a></cite>], success criterion 1.3.1.</p></div> <ul> <li><strong>User Need 7:</strong> Assistive technology users need to be able to review content without being overwhelmed or distracted by information about annotations.</li> <li><strong>REQ 7:</strong> Provide a mode of operation in which information about annotations is suppressed. This mode might be activated by an application setting, such as a toggle switch controlling the presence or absence of annotations.</li> <li><strong>User Need 8:</strong> An assistive technology user needs to be able to navigate between annotations (from previous to next) and to obtain a navigable list of annotations (e.g., a list of comments in a word processor document or on a Web page), in order to read and respond to annotations efficiently.</li> <li><strong>REQ 8:</strong> Provide navigation and content viewing functions and a means of obtaining a navigable list of all the annotations associated with the content.</li> <li><strong>User Need 9:</strong> Assistive technology users need to be able to control the amount of information presented about annotations to prevent becoming overwhelmed while they are reading, navigating, and editing content.</li> <li><strong>REQ 9:</strong> Provide options for the user to limit the amount of detail presented as each annotation is encountered. For example, it should be possible to suppress presentation of metadata or replies to comments, or to alert the user only to the presence of the annotation without presenting the metadata or comment text.</li> <li><strong>User Need 10:</strong> Assistive technology users and users with learning or cognitive disabilities sometimes need support in understanding and navigating annotations that represent comments organized as <em>threads</em> of conversation.</li> <li><strong>REQ 10A:</strong> Ensure that the structure of comment threads is unambiguously presented in the user interface, both via visual cues such as icons and color changes, and programmatically to assistive technologies.</li> <li><strong>REQ 10B:</strong> Enable threads to be expanded or collapsed by the user, and ensure the expanded or collapsed state is disclosed to assistive technologies.</li> </ul> <div class="note" role="note" id="issue-container-generatedID-1"><div role="heading" class="note-title marker" id="h-note-1" aria-level="3"><span>Note</span></div><p class="">REQ 8 may be valuable to users in general, and it should be considered for inclusion as a feature of collaboration tools themselves.</p></div> </section> <section id="version-control-features"><div class="header-wrapper"><h2 id="x4-version-control-features"><bdi class="secno">4. </bdi>Version control features</h2><a class="self-link" href="#version-control-features" aria-label="Permalink for Section 4."></a></div> <section id="version-control-changes"><div class="header-wrapper"><h3 id="x4-1-suggested-changes"><bdi class="secno">4.1 </bdi>Suggested changes</h3><a class="self-link" href="#version-control-changes" aria-label="Permalink for Section 4.1"></a></div> <ul> <li><strong>User Need 11:</strong> Assistive technology users need to be able to read the text with information included about <em>suggested changes</em> (i.e., insertions, deletions, or formatting modifications proposed by collaborators). Assistive technology users and those with learning or cognitive disabilities also need to be able to read content being edited without the distraction of insertion and deletion annotations.</li> <li><strong>REQ 11A:</strong> Provide a mode of operation in which details of insertions, deletions, and formatting changes are appropriately presented as collaborators read the content. These details should include time stamps and identification of who made the change together with any annotations the editor may have provided by way of explanation.</li> <li><strong>REQ 11B:</strong> Provide a mode of operation in which users can read the unmodified content, or if they prefer, the revised content, with suggested changes applied, without any annotations indicating revisions.</li> <li><strong>User Need 12:</strong>All users, and particularly users with color blindness need to be able to distinguish insertions, deletions, and unaltered text effectively.</li> <li><strong>REQ 12:</strong> Provide distinctions over and beyond just color to identify inserted and deleted text as required by WCAG 2.2 <a href="https://www.w3.org/WAI/WCAG22/Understanding/use-of-color">Success Criterion 1.4.1: Use of Color</a>.</li> </ul> </section> <section id="diff"><div class="header-wrapper"><h3 id="x4-2-presenting-differences-between-revisions"><bdi class="secno">4.2 </bdi>Presenting differences between revisions</h3><a class="self-link" href="#diff" aria-label="Permalink for Section 4.2"></a></div> <ul> <li><strong>User Need 13:</strong> Users need to be able to compare revisions in meaningful units (words, sentences, lines, blocks of code, a side-by-side presentation of two graphic renderings, etc.), according to the nature of the content, to maximize comprehension.</li> <li><strong>REQ 13:</strong> Provide at least one mode (and preferably several) that present differences in a content appropriate manner.</li> </ul> </section> <section id="summation"><div class="header-wrapper"><h3 id="x4-3-summarizations"><bdi class="secno">4.3 </bdi>Summarizations</h3><a class="self-link" href="#summation" aria-label="Permalink for Section 4.3"></a></div> <ul> <li><strong>User Need 14:</strong> Users with learning or cognitive disabilities and users of assistive technologies sometimes need support in identifying revisions and understanding their effects.</li> <li><strong>REQ 14A:</strong> Provide, with timestamp and author indication, a mechanism to identify and summarize a series of changes to some portion of content.</li> <li><strong>REQ 14B:</strong> Provide, with timestamp and author indication, a mechanism to identify and summarize individual comment threads.</li> <li><strong>REQ 14C:</strong> Provide, if technically feasible, a mechanism allowing any user automatically to generate a summary for themselves of content or a comment thread at any time. Project editors should have the ability to revise and commit a summary to the content in collaborative development as a permanent feature of the collaborative effort.</li> <li><strong>REQ 14d:</strong> Whenever <abbr title="artificial intelligence">AI</abbr> rather than human authoring is used to generate summaries, indicate that the summary was auto-generated, but also provide the ability for an editor to edit or replace the auto-generated summary. Indicate any special circumstances, e.g. <q>an auto-generated plain language summary.</q></li> </ul> </section> </section> <section id="notify"><div class="header-wrapper"><h2 id="x5-notifications-and-messages"><bdi class="secno">5. </bdi>Notifications and Messages</h2><a class="self-link" href="#notify" aria-label="Permalink for Section 5."></a></div> <p>Collaboration tools may send notifications to the user for a variety of reasons. For example, a user may be notified if a collaborator asynchronously submits changes to a document or project, or adds a comment. These notifications may be delivered via operating system facilities, or by a messaging service, such as e-mail or an instant message protocol. Moreover, the collaboration tool may support commenting, issue tracking, or other forms of interaction via external messaging. These optional capabilities are addressed in the following user needs and system requirements.</p> <ul> <li><strong>User Need 15:</strong> Users who are easily distracted or overwhelmed need to receive only notifications that are crucially important to their collaborative activity.</li> <li><strong>REQ 15:</strong> Ensure that users can choose which types of notifications are delivered, and which are suppressed, according to the nature of the information conveyed.</li> <li><strong>User Need 16:</strong> Users for whom reading text is slow or difficult need information that is important to the task at hand to be clearly distinguished and prioritized.</li> <li><strong>REQ 16A:</strong> Provide a mode of operation in which notifications are short, and links to more detailed information are included. In this mode, full details are not provided in the notification. For example, a user could be notified that a comment or issue has been created, with the full text being available only via a link rather than as part of the notification message itself.</li> <li><strong>REQ 16B:</strong> If e-mail or a similar medium is used to deliver notifications, ensure that the <em>subject</em> of the message clearly specifies the project, document, or issue title relevant to the notification.</li> <li><strong>REQ 16C:</strong> If multiple notifications are provided together (e.g., in a single message), ensure that the user can sort the notifications according to reasonable preferences, for example, most recent first or oldest first. This is applicable, for example, to a series of comments organized as <q>threads</q> of discussion, all delivered in a single summary message to the user.</li> </ul> </section> <section id="access-control"><div class="header-wrapper"><h2 id="x6-access-controls"><bdi class="secno">6. </bdi>Access Controls</h2><a class="self-link" href="#access-control" aria-label="Permalink for Section 6."></a></div> <p>A collaborative environment may provide access controls to restrict the modification of content to specified individuals or groups of users. Moreover, access controls may be applied to the entire content, as in a document which is marked as <em>read-only</em> in a text editor or office application, or they may restrict editing to designated parts. Depending on the capabilities of the application, permissions may be changed by an authorized user during a collaborative editing session.</p> <ul> <li><strong>User Need 17:</strong> Users of assistive technologies and those with cognitive or learning disabilities need to be able to ascertain whether they have permission to edit content, in whole or in part.</li> <li><strong>REQ 17:</strong> Ensure that the applicable permission (e.g., read-only state) affecting content currently in focus is prominently presented in the user interface and that it is made available to assistive technologies.</li> </ul> <ul> <li><strong>User Need 18:</strong> Users, including those with learning or cognitive disabilities and those with assistive technologies, need to be informed of changes made to access permissions that take effect during an editing session.</li> <li><strong>REQ 18:</strong> If an access control affecting the content currently in focus is changed during an editing session, for example by a collaborator, a notification of the change is presented in the user interface and made available to assistive technologies.</li> </ul> <div class="note" role="note" id="issue-container-generatedID-2"><div role="heading" class="note-title marker" id="h-note-2" aria-level="3"><span>Note</span></div><p class=""><cite>Web Content Accessibility Guidelines (WCAG) 2.2</cite> [<cite><a class="bibref" data-link-type="biblio" href="#bib-wcag22" title="Web Content Accessibility Guidelines (WCAG) 2.2">wcag22</a></cite>] should be consulted for guidance on ensuring that the user interface for configuring access controls meets appropriate accessibility requirements.</p></div> </section> <section id="conventions"><div class="header-wrapper"><h2 id="x7-general-guidance-on-implementing-accessibility-features-of-collaborative-environments"><bdi class="secno">7. </bdi>General Guidance on Implementing Accessibility Features of Collaborative Environments</h2><a class="self-link" href="#conventions" aria-label="Permalink for Section 7."></a></div> <p>To facilitate effective collaboration, applications should be designed to respect conventions of user interface design that are likely to be expected by users, including those who have disabilities.</p> <ul> <li><strong>User Need 19:</strong> Users with learning or cognitive disabilities or who use assistive technologies need to learn and use collaboration tools efficiently. </li> <li><strong>REQ 19A:</strong> In implementing collaboration features, follow established user interface conventions and design patterns. For example, use conventional terminology, labels, or icons for functionality that may be familiar to users.</li> <li><strong>REQ 19B:</strong> Support the accessibility-related features of the user's operating system, user agent, and assistive technology. For example, some assistive technologies, such as screen readers, have features designed specifically for reading comments and suggested changes in textual content, which should be supported instead of defining application-specific functionality or keyboard commands that accomplish the same purpose.</li> <li><strong>REQ 19C:</strong> Make collaborative features available via an <abbr title="application programming interface">API</abbr> to allow interoperability with tools with which the user may already be familiar, and which may better satisfy a person's specific accessibility-related needs. For example, a revision control system could interoperate via an <abbr>API</abbr> with a user's chosen text editor or integrated development environment.</li> </ul> <div class="note" role="note" id="issue-container-generatedID-3"><div role="heading" class="note-title marker" id="h-note-3" aria-level="3"><span>Note</span></div><aside class=""> <p>Provision of an <abbr>API</abbr> does not diminish the importance of ensuring that user interfaces provided by the application satisfy accessibility requirements. Nor is REQ 19C applicable to all collaborative environments. For example, some applications are highly dependent on editing functions specific to the tool itself, and should not be expected to interoperate with external editors.</p> <p>Note that learning an unfamiliar user interface is difficult or impossible for some people with learning or cognitive disabilities. Consequently, offering interoperability via an <abbr>API</abbr> with tools that are already familiar to the user can remove otherwise insurmountable barriers to access in such cases.</p> </aside></div> </section> <section class="appendix" id="acknowledgments"><div class="header-wrapper"><h2 id="a-acknowledgments"><bdi class="secno">A. </bdi>Acknowledgments</h2><a class="self-link" href="#acknowledgments" aria-label="Permalink for Appendix A."></a></div> <p>The Accessible Platform Architectures Working Group gratefully acknowledges the vision and multi-year effort of our <a href="https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Main_Page">Research Questions Task Force (RQTF)</a> in developing this publication. In addition we wish to acknowledge the contributions of all who provided comments and suggestions as this publication moved through multiple revisions. We especially thank our colleagues in the <a href="https://www.w3.org/WAI/cognitive/">Cognitive and Learning Disabilities (COGA)</a> Task Force for their particular diligence providing comments and suggestions. Without COGA's help this publication would have been far less formidable. Lastly, we particularly acknowledge and thank David Swallow for his work coordinating issue resolution between COGA and RQTF as our officially designated liaison. He helped us hear each other's concerns more clearly, and that lead to more comprehensive and nuanced requirements above.</p> </section> <script> // <![CDATA[ <-- For SVG support if ('WebSocket' in window) { (function () { function refreshCSS() { var sheets = [].slice.call(document.getElementsByTagName("link")); var head = document.getElementsByTagName("head")[0]; for (var i = 0; i < sheets.length; ++i) { var elem = sheets[i]; var parent = elem.parentElement || head; parent.removeChild(elem); var rel = elem.rel; if (elem.href && typeof rel != "string" || rel.length == 0 || rel.toLowerCase() == "stylesheet") { var url = elem.href.replace(/(&|\?)_cacheOverride=\d+/, ''); elem.href = url + (url.indexOf('?') >= 0 ? '&' : '?') + '_cacheOverride=' + (new Date().valueOf()); } parent.appendChild(elem); } } var protocol = window.location.protocol === 'http:' ? 'ws://' : 'wss://'; var address = protocol + window.location.host + window.location.pathname + '/ws'; var socket = new WebSocket(address); socket.onmessage = function (msg) { if (msg.data == 'reload') window.location.reload(); else if (msg.data == 'refreshcss') refreshCSS(); }; if (sessionStorage && !sessionStorage.getItem('IsThisFirstTime_Log_From_LiveServer')) { console.log('Live reload enabled.'); sessionStorage.setItem('IsThisFirstTime_Log_From_LiveServer', true); } })(); } else { console.error('Upgrade your browser. This Browser is NOT supported WebSocket for Live-Reloading.'); } // ]]> </script> <section id="references" class="appendix"><div class="header-wrapper"><h2 id="b-references"><bdi class="secno">B. </bdi>References</h2><a class="self-link" href="#references" aria-label="Permalink for Appendix B."></a></div><section id="informative-references"><div class="header-wrapper"><h3 id="b-1-informative-references"><bdi class="secno">B.1 </bdi>Informative references</h3><a class="self-link" href="#informative-references" aria-label="Permalink for Appendix B.1"></a></div> <dl class="bibliography"><dt id="bib-coga-usable">[coga-usable]</dt><dd> <a href="https://www.w3.org/TR/coga-usable/"><cite>Making Content Usable for People with Cognitive and Learning Disabilities</cite></a>. Lisa Seeman-Horwitz; Rachael Bradley Montgomery; Steve Lee; Ruoxi Ran. W3C. 29 April 2021. W3C Working Group Note. URL: <a href="https://www.w3.org/TR/coga-usable/">https://www.w3.org/TR/coga-usable/</a> </dd><dt id="bib-concurrency-control">[concurrency-control]</dt><dd> <cite>Concurrency control in groupware systems</cite>. Clarence A. Ellis; Simon J. Gibbs. Proceedings of the 1989 ACM SIGMOD international conference on Management of data. 1989. </dd><dt id="bib-raur">[RAUR]</dt><dd> <a href="https://www.w3.org/TR/raur/"><cite>RTC Accessibility User Requirements</cite></a>. Joshue O'Connor; Janina Sajka; Jason White; Michael Cooper. W3C. 25 May 2021. W3C Working Group Note. URL: <a href="https://www.w3.org/TR/raur/">https://www.w3.org/TR/raur/</a> </dd><dt id="bib-wcag22">[wcag22]</dt><dd> <a href="https://www.w3.org/TR/WCAG22/"><cite>Web Content Accessibility Guidelines (WCAG) 2.2</cite></a>. Michael Cooper; Andrew Kirkpatrick; Alastair Campbell; Rachael Bradley Montgomery; Charles Adams. W3C. 12 December 2024. W3C Recommendation. URL: <a href="https://www.w3.org/TR/WCAG22/">https://www.w3.org/TR/WCAG22/</a> </dd></dl> </section></section><p role="navigation" id="back-to-top"> <a href="#title"><abbr title="Back to Top">↑</abbr></a> </p><div class="dfn-panel" hidden="" role="dialog" aria-modal="true" id="dfn-panel-for-dfn-collaboration-tool" aria-label="Links in this document to definition: collaboration tool"> <span class="caret"></span> <div> <a class="self-link" href="#dfn-collaboration-tool" aria-label="Permalink for definition: collaboration tool. Activate to close this dialog.">Permalink</a> </div> <p><b>Referenced in:</b></p> <ul> <li>Not referenced in this document.</li> </ul> </div><div class="dfn-panel" hidden="" role="dialog" aria-modal="true" id="dfn-panel-for-dfn-suggested-changes" aria-label="Links in this document to definition: suggested changes"> <span class="caret"></span> <div> <a class="self-link" href="#dfn-suggested-changes" aria-label="Permalink for definition: suggested changes. Activate to close this dialog.">Permalink</a> </div> <p><b>Referenced in:</b></p> <ul> <li>Not referenced in this document.</li> </ul> </div><div class="dfn-panel" hidden="" role="dialog" aria-modal="true" id="dfn-panel-for-dfn-tracked-changes" aria-label="Links in this document to definition: tracked changes"> <span class="caret"></span> <div> <a class="self-link" href="#dfn-tracked-changes" aria-label="Permalink for definition: tracked changes. Activate to close this dialog.">Permalink</a> </div> <p><b>Referenced in:</b></p> <ul> <li>Not referenced in this document.</li> </ul> </div><script id="respec-dfn-panel">(() => { // @ts-check if (document.respec) { document.respec.ready.then(setupPanel); } else { setupPanel(); } function setupPanel() { const listener = panelListener(); document.body.addEventListener("keydown", listener); document.body.addEventListener("click", listener); } function panelListener() { /** @type {HTMLElement} */ let panel = null; return event => { const { target, type } = event; if (!(target instanceof HTMLElement)) return; // For keys, we only care about Enter key to activate the panel // otherwise it's activated via a click. if (type === "keydown" && event.key !== "Enter") return; const action = deriveAction(event); switch (action) { case "show": { hidePanel(panel); /** @type {HTMLElement} */ const dfn = target.closest("dfn, .index-term"); panel = document.getElementById(`dfn-panel-for-${dfn.id}`); const coords = deriveCoordinates(event); displayPanel(dfn, panel, coords); break; } case "dock": { panel.style.left = null; panel.style.top = null; panel.classList.add("docked"); break; } case "hide": { hidePanel(panel); panel = null; break; } } }; } /** * @param {MouseEvent|KeyboardEvent} event */ function deriveCoordinates(event) { const target = /** @type HTMLElement */ (event.target); // We prevent synthetic AT clicks from putting // the dialog in a weird place. The AT events sometimes // lack coordinates, so they have clientX/Y = 0 const rect = target.getBoundingClientRect(); if ( event instanceof MouseEvent && event.clientX >= rect.left && event.clientY >= rect.top ) { // The event probably happened inside the bounding rect... return { x: event.clientX, y: event.clientY }; } // Offset to the middle of the element const x = rect.x + rect.width / 2; // Placed at the bottom of the element const y = rect.y + rect.height; return { x, y }; } /** * @param {Event} event */ function deriveAction(event) { const target = /** @type {HTMLElement} */ (event.target); const hitALink = !!target.closest("a"); if (target.closest("dfn:not([data-cite]), .index-term")) { return hitALink ? "none" : "show"; } if (target.closest(".dfn-panel")) { if (hitALink) { return target.classList.contains("self-link") ? "hide" : "dock"; } const panel = target.closest(".dfn-panel"); return panel.classList.contains("docked") ? "hide" : "none"; } if (document.querySelector(".dfn-panel:not([hidden])")) { return "hide"; } return "none"; } /** * @param {HTMLElement} dfn * @param {HTMLElement} panel * @param {{ x: number, y: number }} clickPosition */ function displayPanel(dfn, panel, { x, y }) { panel.hidden = false; // distance (px) between edge of panel and the pointing triangle (caret) const MARGIN = 20; const dfnRects = dfn.getClientRects(); // Find the `top` offset when the `dfn` can be spread across multiple lines let closestTop = 0; let minDiff = Infinity; for (const rect of dfnRects) { const { top, bottom } = rect; const diffFromClickY = Math.abs((top + bottom) / 2 - y); if (diffFromClickY < minDiff) { minDiff = diffFromClickY; closestTop = top; } } const top = window.scrollY + closestTop + dfnRects[0].height; const left = x - MARGIN; panel.style.left = `${left}px`; panel.style.top = `${top}px`; // Find if the panel is flowing out of the window const panelRect = panel.getBoundingClientRect(); const SCREEN_WIDTH = Math.min(window.innerWidth, window.screen.width); if (panelRect.right > SCREEN_WIDTH) { const newLeft = Math.max(MARGIN, x + MARGIN - panelRect.width); const newCaretOffset = left - newLeft; panel.style.left = `${newLeft}px`; /** @type {HTMLElement} */ const caret = panel.querySelector(".caret"); caret.style.left = `${newCaretOffset}px`; } // As it's a dialog, we trap focus. // TODO: when <dialog> becomes a implemented, we should really // use that. trapFocus(panel, dfn); } /** * @param {HTMLElement} panel * @param {HTMLElement} dfn * @returns */ function trapFocus(panel, dfn) { /** @type NodeListOf<HTMLAnchorElement> elements */ const anchors = panel.querySelectorAll("a[href]"); // No need to trap focus if (!anchors.length) return; // Move focus to first anchor element const first = anchors.item(0); first.focus(); const trapListener = createTrapListener(anchors, panel, dfn); panel.addEventListener("keydown", trapListener); // Hiding the panel releases the trap const mo = new MutationObserver(records => { const [record] = records; const target = /** @type HTMLElement */ (record.target); if (target.hidden) { panel.removeEventListener("keydown", trapListener); mo.disconnect(); } }); mo.observe(panel, { attributes: true, attributeFilter: ["hidden"] }); } /** * * @param {NodeListOf<HTMLAnchorElement>} anchors * @param {HTMLElement} panel * @param {HTMLElement} dfn * @returns */ function createTrapListener(anchors, panel, dfn) { const lastIndex = anchors.length - 1; let currentIndex = 0; return event => { switch (event.key) { // Hitting "Tab" traps us in a nice loop around elements. case "Tab": { event.preventDefault(); currentIndex += event.shiftKey ? -1 : +1; if (currentIndex < 0) { currentIndex = lastIndex; } else if (currentIndex > lastIndex) { currentIndex = 0; } anchors.item(currentIndex).focus(); break; } // Hitting "Enter" on an anchor releases the trap. case "Enter": hidePanel(panel); break; // Hitting "Escape" returns focus to dfn. case "Escape": hidePanel(panel); dfn.focus(); return; } }; } /** @param {HTMLElement} panel */ function hidePanel(panel) { if (!panel) return; panel.hidden = true; panel.classList.remove("docked"); } })()</script><script src="https://www.w3.org/scripts/TR/2021/fixup.js"></script></body></html>