Issue 100

index.html

@@ -34,7 +34,7 @@ <h3>What are collaboration tools?</h3>
         </ul>
       </section>
       <section id="distinctive-features">
-        <h3>Our Scope: Distinctive features of collaboration tools</h3>
+        <h3>Our scope: distinctive features of collaboration tools</h3>
         <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"></a>. It is important to consider how these features are manifested in the tool&apos;s user interface. From this perspective, the distinguishing features may be described as follows.</p>
         <dl>
@@ -71,7 +71,7 @@ <h3>Our Scope: Distinctive features of collaboration tools</h3>
       </section>
 
     <section id="need-definition">
-      <h3>Defining User needs</h3>
+      <h3>Defining user needs</h3>
       <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&apos;s ability to respond to potentially disruptive changes introduced by collaborators.&apos;</p>
     </section>
             <section id="collab-a11y">
@@ -90,7 +90,7 @@ <h2>Social Considerations</h2>
 	      <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">
-        <h3>Scope and Applicability of this Document</h3>
+        <h3>Scope and applicability of this document</h3>
         <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"></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"></a> would be relevant to the tool.</p>
@@ -99,7 +99,7 @@ <h3>Scope and Applicability of this Document</h3>
     </section>
 
     <section id="synchronous">
-      <h2>Real-Time co-editing</h2>
+      <h2>Real-Time Co-editing</h2>
       <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>
@@ -143,7 +143,7 @@ <h2>Annotations</h2>
       <p class="note">REQ 8 may be valuable to users in general, and it should be considered for inclusion as a feature of collaboration tools themselves.</p>
     </section>
     <section>
-      <h2>Version control features</h2>
+      <h2>Version Control Features</h2>
       <section id="version-control-changes">
         <h3>Suggested changes</h3>
         <ul>
@@ -157,7 +157,7 @@ <h3>Suggested changes</h3>
         </ul>
       </section>
       <section id="diff">
-        <h3>Presenting Differences Between Revisions</h3>
+        <h3>Presenting differences between revisions</h3>
         <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>

messaging/2.wai-e-mail.md

@@ -1 +1,54 @@
-2024-07 e-mail : https://lists.w3.org/Archives/Public/public-wai-announce/2024JulSep/0001.html
+_Subject:_ For Review: Collaboration Tools Accessibility User Requirements - Updated Working Draft
+
+<s>plain text</s> -- now using HTML e-mail so we can embed links :-) I put "@@" to remind myself ~Shawn
+
+<pre>
+
+Dear WAI Interest Group,
+
+W3C WAI invites you to comment on a Draft W3C Group Note:
+  Collaboration Tools Accessibility User Requirements
+  https://www.w3.org/TR/ctaur/
+
+@@ This is the planned last draft before we publish this as a W3C Group Note.  
+
+Overview:
+
+Collaboration Tools Accessibility User Requirements ("CTAUR") covers accessibility user needs, requirements, and scenarios for collaborative content creation and development tools. It addresses features and capabilities unique to interactive, real-time, or asynchronous collaborative applications. This includes co-editing, revision tracking, and in-line comments.
+
+The scope of CTAUR is broader than web-based word processors; it encompasses a variety of applications across diverse hardware and software environments to comprehensively address accessibility in collaborative editing technologies.
+
+The solutions identified in this document are intended to influence the evolution of future accessibility guidelines, technical specifications, or features of collaboration tools and assistive technologies. They are relevant to software developers who contribute to developing the collaborative experience.
+
+
+Seeking input:
+
+We encourage broad review from a cross-disability perspective. This draft incorporates substantial revisions made in response to comments on the previous Working Drafts by various stakeholders, including especially the Cognitive and Learning Disabilities Accessibility (COGA) Task Force @@ https://www.w3.org/groups/tf/cognitive-a11y-tf. These comments led to the addition of significant requirements as well as to clarification of the document's scope. We especially request comments on the following four questions:
+
+1.  We came to understand the collaborative editing environment in terms of managing complexity. We observed that many word processing, spread sheet, software development, and media development environments are themselves intrinsically complex. To this, collaborative tooling adds a further layer of complexity: the management of proposed, accepted, and rejected edits from multiple participants. Does this framing make sense? Is its importance clearly communicated by the document?
+
+2.  Do we delineate between the content creation elements of software and those relating to managing collaboration sufficiently? Is the distinction meaningfully communicated? Do you agree with this scoping?
+
+3.  We inserted a section in our Introduction on Social Considerations. This brief section is included to communicate which stakeholders we regard responsible for which aspects of collaborative efforts. Is this helpful?
+
+4.  We created a glossary to define the term "WYSIWYG" in response to a comment.  Are there other terms we use you would like defined in the glossary?
+
+Comments:
+
+To comment, please open a new issue in the document's GitHub repository:
+      https://github.com/w3c/ctaur/issues/new
+Please create separate GitHub issues for each topic, rather than commenting on multiple topics in a single issue.
+
+If it's not feasible for you to use GitHub, send comments in e-mail to: [email protected]. Please:
+* put your comments in the body of the message, not as an attachment
+* start your e-mail subject line with: [CTAUR]
+
+Please send comments by @@ September 2024.
+
+Regards,
+Shawn Lawton Henry for:
+Scott Hollier and Jason White, Research Questions Task Force (RQTF) Facilitators
+Janina Sajka and Matthew Atkinson, Accessible Platform Architectures (APA) Working Group Co-Chairs
+Roy Ran, W3C Staff Contact for APA Working Group
+
+</pre>