Meeting minutes
<lisa> agenda
<lisa> https://
<lisa> Requirements See https://
<lisa> Requirements See https://
Lisa: Our main item is going over the collaboration document.
<Lisa> next item
Lisa: The other item is making sure we are already on the same page
Lisa: please sign up to scribe
<Lisa> next item
<Lisa> close item 1
<Lisa> next item
<Lisa> https://
Lisa: We have gone to the next deadline of Making Content Usable
… User testing has happened.
… I have added to the table what I think should happen for the next version (December some time)
Lisa: (displaying action items page)
… Rain and team are working on the analysis of the user testing
… She spoke to those from the W3C at TPAC
… We have to get the mental health proposals in
… There are other proposals related to open issues.
… Rain will be closing what the template will look like for the new draft
… We will have placeholders for things like editors' notes
… We should also have editors' notes for images (which we don't have yet)
… We need the patterns finalized.
… In order to have the needed images.
… In the next month: discussion about what is missing, and feedback from the structure subgroup.
… We will check to see if findability has been addressed.
… We will also need to close issues - we will need Eric for that.
… There is another table for issues needing discussion, and suggestions for the next version.
… We may want to be more in line with RTQF for our issue papers.
… There is also a list of what needs to be done for issue papers.
… We still need to do supported decision making and triggers.
… If you are not sure what to do, please put yourself in queue.
… We have task tables for other things, like the CTAUR review.
… Each subgroup has its own section. Is that too much?
… These sections are aging quickly. Are there any changes you would like?
David S: works ok for me.
Julie: I think it is ok as is.
<Lisa> next item
Lisa: I would like to do the schedule, but we will wait for Rain to be on the call.
… Next week: how we define harm - the accessibility guidelines working group request.
… We do not have a lot scheduled after that.
… I think that is when Rain will share the feedback.
… I will check that with her.
… Anyone else have anything for the schedule?
<Lisa> next item
<Lisa> close item 4
Lisa: At the early time on Thursday - Mental Health subgroup
… We will have an editor's call (planned) at 9 EST
… WCAG coordination group is at the same time our current meeting is, on Thursday
<Lisa> next item
<Lisa> close item 5
<Lisa> next item
Lisa: We are late in our feedback.
… Some members were getting lost in the document, and were not contributing comments.
… We had a meeting to talk through feedback.
… David S notified RTQF of the coming changes.
… Are they still open to changes?
… Then we finish the review?
… Then what?
Janina: The general feeling across WAI is that this is a valuable document that should get published.
… Unless something severely wrong, we are moving to a 1.0 version
… Small things we can fix.
… We think we have benefitted immensely from COGA's comments during the Spring.
… We had wide review in July, which closed in September.
… It is not too late to get something in, but has to be more specific (we will discuss in a moment)
… Hard to read has resonated across WAI.
… Matthew (co-chair) agrees, and Shawn Henry discussed that this has the same format as other documents.
… The review and updating of all the documents is a big job.
… When it happens all AUR documents will happen at the same time.
… If this one is hard to read, it is probably hard to read for lots of people.
Lisa: Is there a point continuing with our review?
Janina: Yes if there are specific questions I can answer.
… We can talk about specifics.
… You (COGA) were heard. We didn't necessarily take all of the edits, but we did update based on the information.
… Whoever wants to be involved in the redesign, that would be good.
… In addition to CTAUR, there are about half a dozen "AUR"s.
… For those who were on the review - John K is not today's call.
Lisa: for some of the requirements - could make it more confusing.
… We had suggestions of additional user needs and requirements in 8
… It was hard to understand, and didn't address the problem from the different side.
… Perhaps 2 more user needs would solve it. Shall we discuss that?
Janina: yes, especially if there is a specific suggestion.
Lisa: (displaying the version COGA was updating)
… 8 is probably to support COGA
… General guidance
… To learn a tool effectively
… User need: to be able to learn collaborative tools efficiently
… It took a while to determine this was for us.
… Recommend: say (reads recommendation from the document) specific example and the requirement.
… Familiar technology instead of conventional.
Janina: we are unclear as to where the boundary of scope is here.
… We are trying to address what is unique to collaborative environments, and not addressed in good software design.
… If it is guidance that involves multiple environments it belongs somewhere, but not here.
Lisa: Live regions is an example of something that addresses things in this environment, but overlaps.
… In terms of other issues brought up here for screen reader users (like notifications, but not overwhelmed) is the basics of how to use live regions
… Which is true for many sites.
<julierawe> Need to step away from my desk—back in a minute, thanks...
Lisa: It is particularly a problem here, even though it is an issue across multiple environments.
… COGA's issues should get similar focus.
… Consistency across a variety of disability groups' user needs.
… This is why "use familiar word" (a well-known issue) should be a requirement
… The requirement for implement ...should add "familiar words" and design patterns.
Janina: I think that would not be a problem. We should capture that in a Github issue.
David S: yes.
Lisa: Add a user need that (reads from the document) includes keep it simple, short critical paths, requirement b - not requiring opening multiple tabs and panels to complete a single task
… Reason: remembering and navigating can disorient a user.
Janina: a good example - I would be interested in adding this
… a good example would be really powerful.
Lisa: requirement C for that - enable a mode for inline changes
… here the example is the difs
… If you do not have a visual memory - comparing 2 different documents is impossible.
… And having a color identifier.
… Having the option for inline changes.
… Example: suggestions can be in a different color from the rest of the text.
… Right now in Github not everyone can understand the HTML changes, then use a diff to compare the current version and the previous
… We are copying out, moving the two versions combined in Google doc
… We use suggestion mode
… Then you can see strikethrough for things which have been changed
… This helps people understand what differences have been made.
Janina: I think the requirement is for a user agent requirement which supports multiple ways for showing a diff
… Strikethrough vs green is still a diff
… It is displayed differently
Lisa: inline
Janina: that might be a useful explanatory note. I think that is already supported in Github
… Someone in the collaborative document - we are trying to be generic
… It is possible to do it, so we need to point out it is important to do it.
Lisa: we have said enable a mode for inline changes.
… Final requirement: when new processes are necessary keep them as familiar to the users as possible
… or added
Janina: Like what?
<tburtin> Can we use screen reader friendly characters/symbols to help identify the color coding?
Lisa: allow the user to roll back the interface
… As people age they can be successful, but cannot learn the new design patterns. That can be really difficult.
… When adding new processes or designs, allowing people to roll back.
Janina: I think of new process is a new feature.
Lisa: they will redesign.
… The 2nd user need: I sometimes need in-page instructions so I can do the correct task.
… We had 2 requirements.
… Instructions in a place easy to find - a place for putting notes.
… Github has this - a place for a pull request template, to follow your team's checklist.
… That is really useful.
… And context sensitive help being available for non-standard elements.
Janina: I am not sure the last one is specific to collaborative environments.
… They are good points, not arguing with that.
Lisa: I am looking at requirement 15.
… For equity.
… Ensure that users can choose which types of notifications are delivered or suppressed.
… Is that true only for collaborative documents?
Janina: you could make an argument that it is also in complex environments.
Lisa: That's my point. But they are common problems in collaborative documents.
… Any application developer could read this and get ideas for user needs for work-based applications.
… Anything that gives lots of notifications.
… So I don't see them as only applying to collaborative documents, otherwise exclude the points.
… I feel the same considerations should be applied to the COGA suggestions.
… I think we need to apply the same approach evenly.
… There were other comments we made where we thought (note: small call) there were things which might not work.
… Example 5.2
… "that's appropriate to the type of content"
… Source code vs natural language.
… I do not understand how you can understand a word out of context.
Janina: I think that is about diffs.
Lisa: I'm not sure, I find it hard to understand.
Janina: I think this might be a place to add the example we discussed before.
Lisa: the AI summaries are also often incorrect. We need to know if the summary is made by AI.
… Another problem with AI - summarizing the changes.
… I didn't think AI could do this. When I do it in Github, or Wikipedia, a summary is not helpful
… What is helpful is "here are the changes from John's review"
Janina: re leaving AI in there - is it more helpful to not have it at all, since you won't get it on a day by day or week by week
… if a human is doing it
… If an AI can provide this is it useful or damaging?
… It might be harmful?
Lisa: I don't know. But at the very least it needs to be marked as AI.
Janina: that's easy. I have no problem with that.
… I kept having difficulty with the Google doc this morning - I can't tell what is still open or still done.
Lisa: what are the next steps?
Janina: a list of some of this that we discussed this morning.
… The colorized diff - that is an easy tweak
… Any kind of summations
… AI should be provided and labeled
… That's an easy fix even for 1.0
… Some of what we discussed today is not hard, but we need a very specific, actionable list.
… I will take up notification filtering - is this is scope or not - that is a legitimate question.
… Are we being consistent is also a legitimate question.
Lisa: we have a half hour after this call if some are available.
Janina: I can stay.
David S: Shall we boil this down to the main feedback.
Lisa: if someone can turn it into a list, that is one task.
… Another task: having more people review the document. John K and I did.
… Any we only looked at the user need part.
… Do we want to carry on with the review?
Janina: we should really think about making the list today or tomorrow.
… There is a desire to publish. There is also the agreement we need to redesign.
Lisa: does anyone want to do more review of the document?
… Anyone else have comments?
Tiffany: I was going to recommend in the Google docs, in addition to color alone, we should have a consistent way to identify for those using a screen reader to identify changes.
Janina: I have no particular experience regarding Google docs - we would need review from some power users of Google docs with screen readers.
… I have no knowledge personally.
Lisa: we should make sure that the information is easily accessed by all users.
<kirkwood> https://
<kirkwood> support info for google doc screen reader capabilities
Jennie: the things I see needing review are future updates related to how people can view/use different types of presentations (both visually and programmatically) once other updates are made to the document.
Lisa: I am adding John's comment in the chat to the document.
Tiffany: for me the screen reader commands within Google docs are complex.
… I use it with vision.
… Dark mode can also change the expression of the colors.
… Having a tag would help for those using dark mode + screen reader.
Jennie: +1 and multiple users would benefit including those with color deficiencies.
Janina: we are talking about a span of content.
… If we talk about something like a magazine article. Some could be expressed through strikeout, or from color. Getting a tag to indicate where to look for this to start or stop - would that be helpful?
Tiffany: It is challenging. Some using limited vision would reserve this for this type of task.
… The tag would get someone with vision to the right spot.
<julierawe> Have to leave for next meeting. Thanks, everyone!
Tiffany: In dark mode someone would know that there is a differentiation.
… Having the tags for start and end point would be helpful.
Jennie: this might be covered somewhat in PDF/UA