<CharlesHall> apologies. dual tasking this morning. squatting on call. may be mostly quiet.
<jeanne> scibe: jeanne
<jeanne> Shawn: We are presenting to AGWG on the Requirements at 11:00am ET today. We need to prepare a summary of substantive changes.
<jeanne> DP-1: changed intersectional - wordsmithing
<jeanne> DP-2: wordsmithing
<jeanne> DP-3: wordsmithing
<jeanne> DP-4: addeed note
<KimD> We're looking at https://w3c.github.io/silver/requirements/index.html#design-principles?
<jeanne> DP-5: Needs definition of plain language, but doesn't need to be called out
<jeanne> DP-6: expanded scope of active recruiting
<jeanne> DP-7: wordsmith
<jeanne> DP-8: expanded. Clarified that it doesn't detract from focusing on needs of people with disabilities
<jeanne> DP-9: added
<jeanne> DP-10: added
<jeanne> Shawn: Requirements were expanded
<jeanne> ... Multiple ways to measure, flexible maintenance, technology neutral.
<jeanne> Kim: people were concerned about "should"
<jeanne> Shawn: because it is in the Design Principles, we can't use "will" because we don't check it off.
<CharlesHall> for reference: https://tools.ietf.org/html/rfc2119
<CharlesHall> and: https://www.w3.org/wiki/RfcKeywords
<jeanne> Shawn: Let's talk to Michael about the best way to handle it.
<CharlesHall> but ‘should’ in a principle is very different than ‘should’ in a requirement
<jeanne> https://www.w3.org/2019/03/29-silver-minutes.html
<CharlesHall> agnostic implies the technology is doubted. neutral implies the technology is not specific.
<CharlesHall> i vote for neutral
<CharlesHall> agnostic: https://www.merriam-webster.com/dictionary/agnostic
<KimD> +1 to neutral
suggestion: impartial?
<Lauriat> https://w3c.github.io/silver/requirements/#technology-neutral
<chuck> Guideline are user-centric. Methods are technology-centric. Guidelines are worded to apply across varied technologies and avoid being technology-specific. The intent of technology-neutral wording is to provide the opportunity to apply guidelines to current and emerging technology, even if the technical advice doesn't yet exist. Technical details are discoverable in the Methods but are not required to understand guidelines.
<chuck> Guideline are user-centric. Methods are technology-centric. Guidelines are worded to apply across varied technologies and avoid being technology-specific. The intent of technology-impartial wording is to provide the opportunity to apply guidelines to current and emerging technology, even if the technical advice doesn't yet exist. Technical details are discoverable in the Methods but are not required to understand guidelines.
Thank you. That helps a great deal. I think technology-neutral works but also no strong opinions
<chuck> neutral +1
<bruce_bailey> +1 to neutral
<jeanne> Chuck: Let's not spend any more time on this, I'll go with "neutral"
<jeanne> https://www.w3.org/2002/09/wbs/35422/SilverRequirmentsReview/results
<Lauriat> Core guidelines are user-centric. Methods are technology-centric. The core guidelines are worded to apply across varied technologies and avoid being technology-specific. The intent of technology-neutral wording is to provide the opportunity to apply the core guidelines to current and emerging technology, even if the technical advice doesn't yet exist. Technical details are discoverable in the Methods but are not required to understand guidelines.
<Lauriat> 3.5 Readability/Usability: The guidelines are understandable by non-technical audience. Text and presentation are usable and understandable through the use of plain language, structure and design.
<CharlesHall> we can conduct usability testing and surveys. we can even use the same or similar questions that were used against WCAG 2 in the original research.
<jeanne> Jeanne: I'm concerned about testing this
<scribe> scribe: Rachael
Jeanne: We will not have time to user test before a CR deadline.
Shaun: Rather than having any and all wording is subject to change before stamp of approval, I think we need to change to a guideline by guideline - is this done and ready?
<CharlesHall> the format should be tested at the prototype phase to validate
Shaun: when we agree, then we should do testing before the full stamp of approval process.
Jeanne: Charles says it should be tested at prototype phase but we are talking about the content.
Shaun: we should test both. We need to make it clear that this is how we are going to test this. We need to move away from the process where any and all wording is subject to change up till it goes to recommendation.
Jeanne: The only person who has a lot of user testing experience at that time was Charles and he has a lot of work. I Think we need to approach this differently.
Shaun: We got broad agreement in the survey results. Is it enough for us to not answer the testability of this or should we move this into a design principle instead?
<CharlesHall> success can also be measured through the openness of participation and feedback
Jeanne: We can also treat this as we are treating it as accessible. Temporarily move it to design principles but with the goal of moving it back.
<CharlesHall> in my opinion, this is different than the guidelines being accessible.
Shaun: Move Requirement 3.5 to a
design principle. Should we merge it with the 5th one?
... We could merge it with the 5th one.
Jeanne: We could then move it back.
<CharlesHall> one of the major reasons for Silver to exist is based on readability and usability being a challenge in the current guidelines
Rachael: I'm hesitant to merge it if we intend to move it back out again.
Shaun: I think we should merge it and not intend to move it back out again. If we have the accessible part then it can move but overall readability can stay as a design principle.
<KimD> readability/plain language should be a requirement
Shaun: Any thoughts on that?
<CharlesHall> Is this based solely on the premise that a requirement has to have a defined measurement of success?
Kim: I do not want to move it out. I think it needs to stay there.
Jeanne: This is the second phase. We are going to write content then go back adn review requirements. What we are saying is that it isnt' measurable so it should be a design principle.
Since we don't have a way to measure it yet, we could move it and add a note. Or we could define how we want to measure it.
Charles: So this is just around the uncertainty of measurement.
<CharlesHall> then each requirement would have to have a defined measurement of success
Shaun: Hesitant about using a different measure for each requirement.
Jeanne: Usability and readability will be determined by broad public review.
Shaun: I wouldn't be comfortable using that as it self selects.
Jeanne: Broad public review is not supposed to be a small
Shaun: But it is.
<CharlesHall> but broad public review would be the method for some of the other requirements. so it seems unfair to say this one requirement must have something different.
Rachael: we could use early user testing and then use that to inform a larger survey later on.
Shaun: We could get a UX researcher.
<CharlesHall> yes. re-use original research methods.
Jeanne: We could also recruit others to redo it. It sounds like we have a few ways to do this. I just want to ensure we don't get caught at the end.
discussion of usability testing.
<CharlesHall> there is user research and usability testing. the former gets qualitative input that includes info about people. the later is both qualitative and quantitative to test a product.
Shaun: I think we can just keep usability testing. We can push this forward as a requirement and see if we get pushback.
<Lauriat> The core guidelines are understandable by a non-technical audience. Text and presentation are usable and understandable through the use of plain language, structure, and design.
Shaun: The one change was updating the scoping of the first sentence. changes "the guidelines" to "The core guidelines"
<bruce_bailey> +1 nice edit, well worth the discussion time, thank you
<chuck> +1
Shaun: Regulatory environment we
didn't get through with the working group. I anticipate a lot
more discussion.
... question on frequency of updating.
<Lauriat> Regulatory Environment: The Guidelines provide broad support, including: structure and content that facilitates adoption into law, regulation, or policy, and; clear intent and transparency as to purpose and goals, to assist when there are questions or controversy.
Suggestion from John Folio: have structure, content, and methodology added
Shaun: I agree
... Question of whether we should explicity include this
audience in other requirements. I think this is a slippery
slope. That the audience is implied in others and this calls it
out only becuase it is so targetted.
Jeanne: In AWGW meeting, I pointed out that we added the audience and requirement to address the rumours that Silver couldn't be used in a regulatory environment.
Shaun: comments on how would we measure success? We discussed this some at the meeting. We will have to measure success in 2 ways. 1. Usability testing with people in regulatory enviroment. How well does this support this aspect of regulatory environment.
How well do we support clear intent and transparency.
<bruce_bailey> +1 to ask about litigation vs regulation and policy
scribe: 2. By real worls adoption and use. We can measure this after the fact.
Shaun: Is that a good enough talking point for the AG?
Jeanne: We can also show it by process. These are the people we involve. These are the regulators. We can demonstrate by showing this is hte process. I'm not too worried about this one.
<KimD> +1
Kim: I agree.
<Lauriat> https://w3c.github.io/silver/requirements/#regulatory-environment
Bruce: At one point we talked
about this requirement also covered litigation. I think that
should be mentioned in the 2nd bullet.
... I don't see it in the design principles either.
Kim: I said contraversy instead since that means a lawsuit to lawyers.
Shaun: And it covers non legal situations as well.
<bruce_bailey> how about: clear intent and transparency as to purpose and goals, to assist when there are questions or controversy or litigation.
Kim: I don't feel comfortable saying litigation becuase the goal of this isn't to support lawsuits. Its to give them information for people to do it themselves, to be clear and transparent.
<bruce_bailey> except that clear intent and transparency helps with adoption in regulation and policy
<chuck> Hard stop, I have to go.
I modeled it after legislative intent. They just say it.
Bruce: I think we need the word litigation. I didn't think that regulatory covered litigation until it was brought up. Both settings need clear intent and transparency.
Shaun: I would also prefer not to use the word.
<bruce_bailey> i can defer
<CharlesHall> litigation happens when there is a dispute. law simply says this thing must.
Shaun: the two bullets cover 1. creation of regulation and 2. making decisions around whether someone is following regulations. If there is clearer wording, the I'm open to it but we are out of time.
<kirkwood> support regulation, support determiniation of intent
??: Can we use unambiguos along with clear?
shaun: Please send suggested wording through email.
k.
trackbot end meeting
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/ag-silver// Default Present: jeanne, CharlesHall, Lauriat, Shri, KimD, kirkwood, shari, bruce_bailey, AngelaAccessForAll, chuck, Rachael Present: jeanne CharlesHall Lauriat Shri KimD kirkwood shari bruce_bailey AngelaAccessForAll chuck Rachael Regrets: Jan Denis Found Scribe: Rachael Inferring ScribeNick: Rachael Found Date: 02 Apr 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]