Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommendations on the document: Collaboration Tools Accessibility User Requirements #64

Open
newtonsgroove opened this issue Feb 29, 2024 · 0 comments

Comments

@newtonsgroove
Copy link

Recommendations on the document: Collaboration Tools Accessibility User Requirements

Consider expanding the scope of this document to include not only collaboration tools, but tools which contain collaborative features.

Consider the following: JIRA, for example, is defined by the owners as a software development tool that allows bug tracking, issue tracking and agile project management. Yet it also has extensive areas of collaboration as defined in the Collaboration Tools Accessibility User Requirements. So, is it then a collaboration tool or a tool with collaborative features? Google Workspace, Office 365, and many others follow this paradigm.

Consider revising the following statement:

“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 WAI-Adapt Task Force.”

WCAG guidelines, for example, have in fact supported dynamic content (as it applies to this discussion) in some way. 2.2.2 Pause, Stop, Hide provides mechanisms to address auto-updating content:in that “For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.” 3.2.2 OnInput ensures “Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.”

From this, a creator of collaboration software would be made aware of potential requirements related to criteria: These include but are not limited to the following:

Provide a mechanism to enable/disable real-time-updates
Provide a mechanism to enable/disable/pause notification of real-time updates
Provide a mechanism to merge updates and be notified about updates on Input
Notify the user upon entrance to the form field in the collaborative tool of the potential of real-time updates (ex: hidden text and/or aria-notifications,)

Some of the examples in the section on Reat-Time co-editing can be linked back to specific WCAG 2.1 AA Success criteria. “REQ 1: Provide a mode of operation in which status messages 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).” could be linked to (4.1.3 Status Messages). Others such as “REQ 4: 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.” are more UX specific and depending upon implementation could potentially span several criteria (2.4.7 Focus Visible, 2.4.3 Focus Order, 3.2.2 On Input, 4.1.3 Status Messages)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant