Meeting minutes
Collaboration Tools Accessibility User Requirements.
jasonjgw: Noting issues 58 & 59 closed with comment.
Janina: plans to review the document in case of modifications that can be made to take further account of COGA issues.
DavidSwallow: Taking up issue 55 ...
Janina: notes our remit is Web applications; desktop applications are out of scope.
<DavidSwallow> #56: In the first paragraph of '1.2 Distinctive features of collaboration tools', consider replacing "web application or with application software in general" with "web applications and software applications in general" as there could be several options.
<gb> Issue 56 [not found]
jasonjgw: Checking whether that's still text in the current draft ...
DavidSwallow: It is still there
DavidSwallow: Clarifying grammatical number issue
jasonjgw: Will push the change now.
DavidSwallow: Issue 54
Janina: this is a matter of common interface strategy; we need to adopt conventions that have been established (common keyboard commands etc.). Having an example would be useful.
Janina queries what the proposed example amounts to - that right-click should - should not - invoke a context menu?
[Group is inclined to accept in a general way, but the example doesn't seem the best example.]
DavidSwallow: issue 53
DavidSwallow: A bit like Content Usable in issue 59
<janina> s/content usable/Content Usable/
Janina: inclined to accept, but the reference should be to WCAG 2.2.
Janina: we can only normatively refer to/require what is in WCAG 2.2.
[we accept with above amendments]
Janina suggests Content Usable is a suitable reference for the bibliography.
jasonjgw: Will take the action
DavidSwallow: Issue 52
<DavidSwallow> "For collaboration tools that also allow document editing, editing tools/collaboration tools should be available, as well as a view, in a method that is very familiar to both document editors and collaborators."
scott_h: Wonders whether this relates to standard interaction paradigms as we discuss
scott_h: obviously, getting a browser to mimic desktop behavior is tricky at best
jasonjgw: What's familiar to one could be unfamiliar to someone else. So, gating on "familiar" is problematic.
janina: Suggests a few examples might help us tease out the design pattern COGA is thinking of
DavidSwallow: 51
DavidSwallow: Add new section after "Suggested Changes" sections
DavidSwallow: Make discovering permissions straight forward
scott_h: Broadly supportive of this
jasonjgw: Also inclined to accept, but not sure it belongs there
janina: Or as its own section?
jasonjgw: multi-user access controls
scott_h: Agree it's just discovery and should be easier to do
jasonjgw: Worried about varyingpermissions across sections/parts of a document
janina: That only escaltes need to discover accessibly what permissions pertain at current focus locus
scBeing able to identify
~.
ssh opera
Jason: worries that a requirement mentioned in an introductory section but not in the main text will be overlooked.
scott: Inclined to say it does belong in this list
janina: Yes to putting in this list, but expounding on access control section elsewhere in the document as well
jasonjgw: Will take up an access control section and then enumerate something in this intro list
DavidSwallow: issue 50
DavidSwallow: A sentence about reviewing history
<DavidSwallow> "The ability to review history easily can be especially important for people who need to remember how something happened or changed."
[disposition is that a better explanation of what's missing from version control could go elsewhere in CTAUR, but this section is an introductory scoping section only, not feature explanatory]
jasonjgw: Actioned to close with comment
DavidSwallow: issue 49
<DavidSwallow> "Use plain language names for each feature or process. Example: Using words like "fork" do not describe the feature using concrete language related to the task. Use chat instead of IRC."
DavidSwallow: plain lang -- but seems out of place for the same reasons
janina: plain to who? The audience is developers, not Joe Sixpack
jasonjgw: Yes
jasonjgw: if you don't use the expected term, your meaning can be lost
scott: Agree--We ran into this in RAUR.
janina: Yes this is about introducing COGA reqs, but the audience is developers who expect certain terminology
[we do not accept as described above]
jasonjgw: Action close with comment
scott: Notes some good info in recent plan lang standard
jasonjgw: topic:
COGA asking for RQTF research process documentation?
scott: I wrote a draft but we had no comments
jasonjgw: Exactly. It didn't go further because no comments
janina: Need to find the link