Meeting minutes
Collaboration Tools Accessibility User requirements.
jasonjgw: Notes created a PR adding section to introduction regarding better scope definition
jasonjgw: We're seeking to cover a range of tooling is the intent
jasonjgw: Add an exaple
Janina: raises the question of how to read the pull request in context.
jasonjgw: Best, esp on shell, is gh pr checkout [pr number]
jasonjgw: then use gitlog to read
jasonjgw: gitlog -p provides changelog
jasonjgw: then loading the branch into a browser is final approach
jasonjgw: Notes his 3 PR are each confined to a single section, not edits scattered throughout the doc
jasonjgw: Other questions/comments?
Janina would like the pull requests to be resolved before undertaking a further round of edits.
Janina read the document throughout, attending to coverage of graphical objects, structural reorganization, etc.\Janina would like to attempt revisions.
Janina: it isn't clear we have additional distinctive features with respect to object manipulation.
Janina would like to add a higher-level organizational view that is currently absent from the document (e.g., document reorganization, editing of graphical/audio objects).
jasonjgw: Suggests asyncronous resolution -- by Friday meeting time
[group agrees]
subsection: Issue 44 & 45
DavidSwallow: Sec 3 Realtime Coediting -- Common Pitfalls
DavidSwallow: lacking a real home in doc struct
<DavidSwallow> User Need X: As a user who has difficulty with organization (executive function), typing, and putting letters and numbers in the right order, I want an interface that stops me from making mistakes, and helps me complete tasks successfully.
<DavidSwallow> REQ X: Help users correct mistakes. A good design makes errors less likely. When errors occur, the user should find it easy to correct them. Be forgiving. When the user makes a mistake make it easy to roll back, make changes, undo and go back.
jasonjgw: Facilitator question: Is there a specific collab point here that wouldn't be a text editing point
ScottSounds like version control
jasonjgw: Should anyone be empowered to revert changes? Unclear about collab
DavidSwallow: probably is general ability --
janina: Could be COGA not groking that distinction yet
jasonjgw: Notes one PR is the new permissions; Asks Scott to check Pr
Janina: we also address this in our preference for standard key bindings and support for AT features.
Janina finds it unclear from the COGA TF comment whether there's a structural orgnaization issue here.
Janina: we have two actions: (1) reviewing the proposal on permissions, and (2) Janina's proposal to address structure editing as a collaboration strategy.
Janina: the latter could help in understanding structural organization.
Janina: we won't discuss general text editing UIs, as this is not specific to collaboraiton environments.
janina: Hopefully my prespective pr closes this issue
subsection: Issue 43 & 42
<DavidSwallow> User Need X: As a user who finds some web sites hard to use and struggles with finding the right control for what I need to do, I sometimes need in-page and inline support so that I can use the content. However, with an attention impairment any support required needs to be in my control to avoid distractions.
<DavidSwallow> REQ X: Provide help. This includes: • All functions and tasks have good instructions in easy to understand language • Instructions are complete, and do not miss out steps • Images are used so I can clearly see what to do • Instructions are easy to find for every step where it may be needed • Provide instructions for screen reader users • Enable document search, though comments, annotations, collapsed sections, etc. Document [CUT]
Janina: this pertains to editing in general, not to the collaborative aspect.
jasonjgw: rt collab editing is less distracting if others aren't also editing the same section
jasonjgw: Solution is social; one at a time in a given area of content
janina: Suggests possible tech solution that locks for only one editor at a time; and locks only a paragraph or similar object to one person
Janina notes that preventing distracting changes made by other simultaneous collaborators applies to all kinds of content - graphical, textual, etc.
jasonjgw: Will create a pr to capture this
subsection: Issue 41
<DavidSwallow> People with cognitive disabilities and attention-related impairments can also lose their train of thought and orientation due to interruptions from messages, notifications and other similar noises and distractions.
janina: Notes already there
scott: agrees
Janina doesn't think there's a need for the additional detail, and the point is already made.
Janina (responding to Raja's question about synchronous vs. asynchronous collaboration) - we're interested in synchronous at the moment.
Janina agrees that the synchronous kind of collaboration is the more challenging issue - e.g., potentially conflicting edits of the same text.
[group consensus to close 41]
subsection: Issues 35 & 36
<DavidSwallow> User Need X: As a user with a memory impairment, attention impairment, or executive function impairment or as a user with a communication disability who uses symbols, I need to know the purpose of the content so that I know if I am in the right place, and what I am doing, even if I lose attention and focus for a time.
<DavidSwallow> REQ X: Help the author make the topic and connections to other documents is clear. For example, provide automated breadcrumbs showing the drive name and the document title.
jasonjgw: Seems generic editing advice
Janina notes there's an issue regarding the inclusion of AAC symbols in collaborative environents. There is an ADAPT spec proceeding through the W3C process, and it appears some browser vendors are interested. If we can describe how it should be used within a collaborative setting, this would be valuable.
Janina asks whether there are requirements on the UI of the tool in addition to what the author may do in creating the content.
Janina notes that converting/translating the symbols is what ADAPT is meant to achieve; some collaborators may not be symbol users.
Janina suggests the symbol content should just be available, assuming the collaboration environment supports it.
Janina: symbols that designate comments, changes, notifications, etc., could be integrated into the UI of the collaboration tool.
jasonjgw: Suggests AAC in each section?
[discussion whether a global section or comment on AAC support item by item]
jasonjgw: We can consider and integrate
jasonjgw: Reminds everyone open pull comments due by Friday, else prs will be applied