<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?
https://docs.google.com/document/d/17tWKnweNC-BJunhtPTGtbYhV2D6VPYDxEofazhGG3Pw/edit#
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.
<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?
scribe Jan
<jeanne> scribe: Jan
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: 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.
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.
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
https://drive.google.com/drive/folders/1uU3_rH7hwHm01OM8GTluz4tn0ed1V2Gm
<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?
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]