Requirements change summary

<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

Technology Neutral

<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.)