Silver Community Group Teleconference

17 May 2019


jan, jeanne, shri, Cyborg, bruce_bailey, Chuck, Makoto, Cyborg_, Lauriat, RedRoxProjects, CharlesHall, johnkirkwood, KimD, EricE


Get set up and review yesterday's work

<jeanne> Short link to the wiki https://bit.ly/2P13Bgp

<Cyborg> webex info?

<Cyborg> are we still waiting to get into room?

<Cyborg> is there webex info?

<Cyborg> ?

<Cyborg> i'm here

<Cyborg> on mute, but on call

<Chuck> Cybele, you there? You are free to call if you have time to continue the review.

scribe jan

cybele and chuck have been looking at user needs and they realized that there is a need for some instruction in the style guide for how to systematically define the user needs.

scribe: we identified 4 steps
... consider all of the user groups, one at a time, as if you were an advocate (self or secondary advocate)
... for example, for color contrast users are people who are color blind and have difficulty distinguishing between foreground and background
... second group are people with visual impairments, have reading glasses, seniors, etc.
... third group were users with cognitive disabilities who might find the content overwhelming.
... we next looked at user needs to find core needs of the users
... looking at this as the trunk, rather than the branches of the user needs.
... first need identified ... users need to distinguish media elements in the foreground, including text and other content from each other and to distinguish foreground from background - this is the trunk
... the next step is to identify a term that needs description in order to understand ... are there examples that need to be identified - this becomes the second sentence
... media elements can become emphasized in the foreground
... the next consideration is what is the core of the solution needed to meet the need. For example, color contrast must be sufficient, but not overwhelming for each user's needs.

<Chuck> I'm now in the conference call.

scribe: After you go through this process, you need to do a plain language review and make modifications.
... the short description you develop will become the "why" in the plain language prototype and the "who" from that prototype will be the user groups identified in the first step
... in summary, the first step is to identify the user groups and the barriers they are experiencing

<Shri> Can anyone please post the link for the color contrast?


Cyborg: Process for Writing Guidelines
... Consider who EACH the user groups are, one at a time, and their individual barrier (as if you were a self-advocate or other advocate). This becomes the who in Get Started page.
... step 2: Identify their core collective need and if there are several unique needs, list them. Metaphor: If unique needs of each group are branches, what is the trunk? This becomes your new first sentence of User Needs.
... another way to word step 2: Identify common need across all user groups and if needs are in conflict, identify specific needs of specific user groups. This becomes your new first sentence of User Needs.
... step 3: Are there terms in the short sentence that need specific examples or description to explain the context? This does not replace eliminating words nor is it a glossary. This becomes the second sentence of your short paragraph of user needs.
... step 4: Write the crux of the solution to meet that need. That is a minimal concept. It becomes the third sentence of the short description
... step 5: Consider the perspective of a beginner user. Re-draft the paragraph so your beginner user will have a functional understanding of the paragraph. This becomes the User Need in the Get Started Page (under Why?)

Jeanne: I wonder if we should write the extended part first and then write the shorter version

Cyborg: Like the summary?

Jeanne: I don't think that one sentence would be the summary ... it might be part of the summary, but we would have other needs.

After multiple edits, the new step-by-step Process for Writing User Needs, is as follows:

Step 1: Consider and list as bullet points who each of the user groups are, one at a time, and their individual barrier (as if you were a self-advocate or other advocate). Write this list in the User Needs Extended Description section.

Step 2: Identify the common need across these multiple user groups and write it as the first sentence in User Need Extended Description. Identify unique needs of specific user groups and include those as bullet points. Identify conflicts that may exist within and between user groups, and list these conflicts as additional bullet points.

Step 3: Are there terms in the short sentence that need specific examples or description to explain the context? This does not replace eliminating words nor is it a glossary. This becomes the second sentence of the User Needs Extended Description.

Step 4: Write the crux of the solution to meet that need. That is a minimal concept. It becomes the third sentence of the User Needs Extended Description.

Step 5: Consider the perspective of a beginner user. Re-draft the paragraph so your beginner user will have a functional understanding of the paragraph. Copy the refined paragraph and bullets into Step 4 Get Started under Why?

Step 6: Refine list from Step 1 in plain language. Copy this into the “Who?” in the Step 4: Get Started page.

Step 7: Write a one sentence summary line of the user needs paragraph. This becomes the short description of the “identifying user needs Short Description” as well as the first sentence of the “Summary” in the Get Started page.

Pain Points in Writing Guidelines

<Chuck> Sorry, I answered for Cybele.

Bruce: One challenge I am feeling is that without the benefit of the group feedback, there's no way I could have done this on my own.

<Chuck> My mouth engaged before my brain processed.

Bruce: my biggest concern is that two weeks from now when I can sit down and do this again, I will forget what I have learned through the rich experience I've had this week is not in the forefront of my mind.

Cyborg: If you were working on your own, what are the most difficult parts of this exercise that would be troublesome without input from others?

Bruce: It's hard to tell where those pain points are because I've been able to write a little and get feedback and then write some more.

Jeanne: One of the things we used to do in ATAG is that we formed small working group calls and we would review the individual work people did. We would do this in small groups because that was easier than working individually and then coming to a larger group to share.

Bruce: Maybe we could set up weekly blocks of time (maybe 3 hour-blocks ... ) where you can dial in and be on the phone as you're working on text

Amy: Open phone / open chat is a helpful model and I have found that to be useful on other projects.

Jeanne: I can see setting up those calls.

Amy: I would be happy to host them on the EU time zone

Cyborg: I noticed that one of the things that helped yesterday, we were working on Bruce's ... I am wondering if we could have a process walk-through / example would be helpful.

Jeanne: We have our regular Silver call today with the rest of the group, but we might consider having a future group meeting where we walk through one of these.
... on today's call, I want to give everyone the opportunity to walk through what we've accomplished in the meetings this week.
... POUR will become tags, but will no longer be the document structure.

<jeanne> Style Guide https://docs.google.com/document/d/1sInhvjkvq5WASlOrEMfshAZSVQB8kM1clRWfGXfVEFI/edit#

Jeanne: When we originally started with this, we had sections. Each section had a short description and a long description. We were told not to use "long description," so we had to give each section, "extended description."

<bruce_bailey> at shri request, I working on tabular version of silver version and migration mapping

<bruce_bailey> i will share the link in a few minutes, but it is in the google doc folder already

<bruce_bailey> https://docs.google.com/spreadsheets/d/1W5CSvU4XxWXNneu4ibokjcYUCsG386xL1rGOiTrDvt8/edit#gid=0

<Chuck> Jan: Are we using the dial in or webex?

<Chuck> got my answer

<johnkirkwood> new webex?

REgular Silver Meeting

scribe Jan

<jeanne> scribe: Jan

AccessU Recap and Results

Jeanne: We started out the week setting up a template that combines the plain language prototype and information architect prototype.

<bruce_bailey> template for guidelines

<bruce_bailey> https://drive.google.com/drive/folders/138a_4_EV8kyF38vY_M2GomPD06vDwaP2

Jeanne: we then did a practice guideline for headings
... we walked through the Headings guideline on Wednesday and then we had Silver members pick a guideline and start working through the template to write the guideline.

<jeanne> https://www.w3.org/WAI/GL/task-forces/silver/wiki/Main_Page

Jeanne: From the wiki - you can find links to all of the current work under section 9 (Content)
... we received 2 guidelines from COGA and we started to move their information into the new template

Bruce: What are the 2 guidelines we worked on from COGA?

Jeanne: They are enable APIs and clear words

<bruce_bailey> https://docs.google.com/spreadsheets/d/1W5CSvU4XxWXNneu4ibokjcYUCsG386xL1rGOiTrDvt8/edit#gid=0

Jeanne: today, we have been talking through what works and doesn't work from the template and we've been trying to streamline everything.

Bruce: This taking something that we had on the whiteboard here and putting it into a structured format.
... first column are the writing instructions from the template
... middle column is the Silver component (user needs, how would we test, writing methods, writing the extended guidance from the plain language prototype, writing the short guideline, determining tags that need to be noted
... third column is the WCAG 2.0 / 2.1 components - the fourth line (extended description) is not intended to be final ... there is a good bit of rewriting that has to be done.
... one of our current goals for Silver is that it address methods that are not limited to Web
... principles from WCAG 2.0/2.1 will mostly appear as tags, but A, AA, AAA will be going away

Jeanne: Under "getting started" - that is going to be copied from the user needs

Bruce: Where was the thing we did earlier?

Jeanne: I copied what we did in Color Contrast and pasted it into the style guide and then I started to work on edits that we were discussing before lunch
... silver style guide is linked from the wiki

<jeanne> https://docs.google.com/document/d/1sInhvjkvq5WASlOrEMfshAZSVQB8kM1clRWfGXfVEFI/edit

Jeanne: There's a new section called, "writing the user needs" - this is the work that we did this morning
... while there's still good information we can copy from WCAG, starting from the user needs helps us to think differently about the detail we need to add to the user needs

<CharlesHall> was there any thought or discussion on the actual vocabulary used to describe a ‘user need’?

Charles: I meant to follow the intent of what this is describing by identifying the functional need instead of the disability name.

Jeanne: That is an excellent point that we did not discuss and we should add that to the style guide.
... Charles, do you have time to address this in the style guide?

Charles: Not really, but you can lift some of the stuff I wrote for the hueristics
... we need to look at the contextual needs and not the type of disabilities

Jeanne: heuristic is linked under conformance on the front page of the wiki

Bruce: We had a lot of discussion about "cannot see" vs. "blind" ... I think that it would be good to have this written down. We also discussed using disability, rather than "impairment."
... there are a lot of context where you need captioning - would there be situational context where audio description would be appropriate.

Charles: example ... people who leave a room while they're watching something and they want to be able to keep up with what is going on visually

Jeanne: The question is "should we include examples beyond people with disabilities as examples for silver?"
... there is a vocal contingent within W3C that believes accessibility guidelines are diluted if we start talking about people without disabilities, but there's another group that believes it makes it easier to persuade others if we can show that this helps a broader base of user.

Shawn: can we say that this kind of wording for user needs makes sense and when we get to situational impairments separate from disabilities, we can address it later?

JohnK: I agree with that, but by saying that "it has nothing to do with disability" that's where the cognitive space can be dismissed.

Shawn: I don't think we're at the point where we're writing about situational impairments.

Jeanne: It came up with several of the guidelines we were writing this week, so I think that we need to address the topic soon.

Charles: I think as a general principle, we should be describing the need and not the user, so in the context of describing the user need, we don't need to distinguish between disabilities and "situational disabilities."

<johnkirkwood> +1 slowed processing speeds?

Cyborg: Depending on the way things are phrased, it can unintentionally exclude people with cognitive disabilities, so we need to be careful (example: a person with visual spatial impairment may take longer to process something)

<bruce_bailey> i made a pass at updating short User Need for Audio Description based on this conversation

Jeanne: We talked about having an overall statement and then we would have bullets that would address particular user needs

<bruce_bailey> https://docs.google.com/document/d/1BJzDxztJhd_hRBQSO0UtWECmUegA-hwucedrayB9VEs/edit#heading=h.w0835p9hewv6

Jeanne: as a general principle, addressing it as a function makes sense, but it can't necessarily be a hard and fast rule

<bruce_bailey> Changes currently showing as "suggestions"

Cyborg: That can be described within the function. It might be about using multiple words to describe a family of functions.
... in doing that process, this was about migration. One concern I have now is that it falls short when addressing new content. Step one is more like personatype work, as opposed to real users; when we migrate content, we won't have to go back and do that kind of work, but when people are proposing new guidelines, you will need to add additional detail.

Jeanne: We can either look at a couple of SCs that we worked on, or we could look at COGA, or we could move to the migration plan

Shawn: I would like an overview of how it went writing content

Jeanne: I was surprised at how much harder it was than I expected

<bruce_bailey> +1 much harder than i expected

Jeanne: we wrote a lot of new tests
... we wrote up a new way to do a rubrics test

<jeanne> https://docs.google.com/document/d/1sInhvjkvq5WASlOrEMfshAZSVQB8kM1clRWfGXfVEFI/edit

Jeanne: Go down to step 2, "How would we test" ... scroll down to new rubric for evaluating quality headings?

<jeanne> https://docs.google.com/document/d/1IVmg0MVHeJipg2ovENQtIkCzbq2izWeGKWaIqYLf0M4/edit#heading=h.70i9zxlz0044

Jeanne: We came up with a list of four questions that reviewers would use and then we came up with a rubric (poor, fair, good, and excellent).
... we also wrote a task completion test
... we are starting to figure out how to do some of the quality measurement test that don't involve testing with people with disabilities

<CharlesHall> I’m not sure about the use of ‘logical’ in “Does the heading order make logical sense?”

Jeanne: Shri came up with the idea that we should move all of this into a form so that we're collecting the information into a database.

Shawn: When we're at the point where we're ready to write at scale, we should do that, but we are still working out the structure right now.

Chuck: Cyborg and I ended up pairing up to work on this and we found that there was a lot of benefit to a paired effort.
... this helped elevate the process and the quality of the work

Jeanne: Amy had an idea of setting up blocks of time and being on a call together.

Working in groups

Cyborg: This idea came up during a discussion of pain points about the process - especially in the context of people being asked to follow this process on their own to complete guidelines. What do we need to do address abandonment.

<bruce_bailey> i understood the suggestion to be to have longer weekly "open call" meetings

Amy: Bruce suggested blocks of time and so I mentioned that I have worked in groups in other projects where we have an open call while we work, so that if we come upon something that we're struggling with, we can ask for help in real time because we're in a call for the purpose of completing work.

<CharlesHall> added comment to rubric in Headings doc

<bruce_bailey> there would need to be a few per week, to accommodate different time zones

Amy: I would be happy to host a working session in the EU time zone

Bruce: Is this making sense for others on the phone who are hearing this for the first time?

<CharlesHall> +1 to pair work

<jeanne> https://docs.google.com/document/d/1zFgVcDUMSOrZ5nnGRocs2pZYkqOhwdyMU_Z62_CedbQ/edit

Shawn: Yes, this makes sense. We should capture ideas like this in our Project Plan Document. We have a whole section on process (communication paths, how do we handle emerging tech, etc.)

<KimD> +1 for me (although my schedule is tight)

Bruce: I am hoping we can shift to the open call structure quickly

Cyborg: We talked about a walk-through. We could maybe do this as a video, or an EO project to help bring people onboard.

<CharlesHall> there is an emerging trend in posting “office hours”. I will be doing this after June, so that my availability to discuss or work on accessibility is publicly available. I could share it with the mailing list for this idea of pair work.

Cyborg - we could do a video or a combination of a slide deck and a video.

COGA submissions for new Silver guidelines

Jeanne: We have a separate page in the Silver content area called "potential guidelines in silver" and that is where I put the COGA guidelines.

<jeanne> Enable APIs https://docs.google.com/document/d/1zI-JOsh1IHjzMoF2aHsHpYynr4vLdFHp69zdgi3sNyo/edit#heading=h.kf50uks5jtu2

Jeanne: "Enable API's"
... I would invite others to use and comment on it
... they took the information architecture template from last year; they followed that and wrote new content for allowing API's to work with content; there's a section in it on the internet of things (IoT), which I think may need to go into it's own SC
... they also wrote some methods and some tests.
... Becky Gibson came to our meeting yesterday and took the COGA SCs and put them into the new template
... you can find those in the Content folder in Phase 4


<jeanne> https://drive.google.com/open?id=1imkVmNUXwzs1ZbfCnuraWOyR8cZ3GaPXFHfAmzRzwwg

Shawn: I am trying to understand the user needs - the short description doesn't make sense to me on a technical level.

Jeanne: It's a positive way of saying, "don't block APIs from working
... we need to look at what Becky did with this and see if she explained it differently

Amy: one example would be trying to copy from a password manager into a password field.

Shawn: So, this is an overall robust guidance "code it right and don't break things.

<bruce_bailey> My example is with Regulations.gov which warns users (citizens trying to submit comments) that plug-ins like Grammerly may not work.

Jeanne: The other one they provided us is "clear words."

<jeanne> Clear Words https://docs.google.com/document/d/1XdI8vuEunDOcIJ0kY2eKGpCKxndEvflEDp737Q148IQ/edit

Cyborg: I think there's a lot of work that needs to be done on this, including not calling it "enabling APIs"

Jeanne: I think there are some good examples of new forms of testing that couldn't be done in WCAG, but could be done in Silver.
... we would want to take them through our new process of developing guidelines in Silver. They didn't have the benefit of that because we just started working on that this week.
... it's not in any kind of final form, but there are some creative, new ideas.

<johnkirkwood> bye

<Cyborg_> are we continuing

<Cyborg_> or are we done for day?

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/05/17 19:31:37 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/personal / persona/
Succeeded: s/code is right/code it right/
Present: jan jeanne shri Cyborg bruce_bailey Chuck Makoto Cyborg_ Lauriat RedRoxProjects CharlesHall johnkirkwood KimD EricE
Found Scribe: Jan
Inferring ScribeNick: Jan
Found Date: 17 May 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]