Minutes of the Silver meeting of 26 March 2019

The W3C bot for taking minutes wasn't started so we do not have nicely 
formatted minutes.

The topics were:

 1. TPAC Scheduling update
 2. Requirements document:  Design Principles 5-10

==Present: ==

jeanne, Chuck, JF, Charles, AngelaAccessForAll, shari, Lauriat, 
Jennison, Cyborg, Jan, KimD,  Lauriat_, bruce_bailey,  Makoto, kirkwood, 
dboudreau, Rachael_, CharlesHall

==IRC log==

01[09:31] <jeanne> agenda+ TPAC scheduling update
01[09:31] <jeanne> agenda+ Requirements
[09:33] <Zakim> agendum 1. "TPAC scheduling update" taken up [from jeanne]
01[09:34] <jeanne> Shawn: AGWG will send out a survey to see whether or 
not we should overlap with AGWG.
[09:34] <bruce_bailey> q+ to suggest day
[09:36] <CharlesHall> I will likely attend, but have no preference
01[09:37] <jeanne> Bruce: prefers not to overlap
[09:37] <Lauriat> agenda?
01[09:37] <jeanne> JF: Will not be attending
[09:37] <dboudreau> Can't attend either, so no preference
01[09:37] <jeanne> zakim, take up next
[09:37] <Zakim> I see a speaker queue remaining and respectfully decline 
to close this agendum, jeanne
[09:37] <JF> Q?
[09:39] <KimD> 
https://www.w3.org/2002/09/wbs/35422/SilverRequirmentsReview/results#xq4
01[09:39] <jeanne> 
https://w3c.github.io/silver/requirements/index.html#design-principles
01[09:42] <jeanne> Topic: Design Principle 5
[09:42] <Lauriat> Added note: define for translation using an 
internationally accepted definition
01[09:42] <jeanne> JF: We need a definition of plain language, 
especilly in the context of international translation
[09:42] <dboudreau> Isn't there an already agreed upon defijnitio for 
plain language out there, though
01[09:42] <jeanne> Jeanne: We should find an internationally accepted 
definition, not make up our own.
01[09:43] <jeanne> Topic: Design Principle 6
01[09:44] <jeanne> JF: Needs editorial finetuning in the second sentence
01[09:45] <jeanne> Topic: Design Principle 8
06[09:46] * jeanne asks Denis if he has a link to that existing defintiion?
01[09:46] <jeanne> Shawn: I have a note to flesh out the design 
principle more.
[09:46] <KimD> Design Priniciple 8: The creation process for the 
guidelines should: Strive to be data-informed and evidence-based.
[09:47] <Cyborg> Present+
01[09:47] <jeanne> Shawn: There are word-smthing suggestions in the 
survey.
01[09:47] <jeanne> present+
[09:48] <Cyborg> can someone please repost link to the survey?
01[09:48] <jeanne> Charles: There is a question whether it applies to 
the Requirements or the Guidelines
01[09:48] <jeanne> 
https://www.w3.org/2002/09/wbs/35422/SilverRequirmentsReview/results
[09:49] <Cyborg> re: evidence-based and data-informed, seems like a 
journey that we need to encourage.
[09:49] <Cyborg> partnerships with academic institutions etc
[09:50] <Cyborg> is there a way to include in Silver some measures to 
encourage the growth of that kind of research?
01[09:50] <jeanne> JF: There may not always be evidence, and we may 
have to rely on anecdotal evidence
[09:51] <Cyborg> what would be awesome, in relation to what Jeanne just 
said, is if we could encourage the growth of PWD-driven research
01[09:51] <jeanne> Jeanne: We may also include experience of people 
with disabilities as a balance.
[09:51] <CharlesHall> perhaps we de-emphasize any implication that data 
= a threshold of statistically significant data?
01[09:53] <jeanne> Charles: The intent is not making arbitrary decisions
01[09:53] <jeanne> JF: I agree with the principle of encouraging growth 
of PWD-driven research, but I think it is outside the scope of this 
project.
01[09:54] <jeanne> ... I recommend talking to Research organization in 
APA, or suggest it to WAI.
01[09:54] <jeanne> Cybele: Can we connect with those groups?
01[09:55] <jeanne> JF: We want to encourage research, but that is not 
related to Guidelines.
01[09:56] <jeanne> Cybele: If someone submitted a Method, and people 
with disabiltities stated that the Method didn't work, how would we deal 
with that situation?
[09:56] <Cyborg> especially if there wasn't research to back-up that 
method - PWD lived experience vs unresearched method?
01[09:56] <jeanne> JF: The AGWG reviews Techniques as a process to test 
them for suitability and applicability.
01[09:57] <jeanne> ... the review of Methods and ongoing updates of 
Silver guidelines are going to continue to be a responsibility of AGWG.
[09:58] <Lauriat> Suggest adding note on this: reword to focus more on 
making informed decisions, rather than implying a specific level of data 
required or research conducted.
01[09:59] <jeanne> Jeanne: What we have discussed is that submitting a 
new Method has to show that the Method actually works
[10:00] <JF> +1 to Jeanne.
01[10:01] <jeanne> Cybele: It would be ideal if every Guideline and 
Method has reseach behind it.
01[10:02] <jeanne> Jeanne: I don't think we can do that for existing 
WCAG we are migrating.  There are about 700 existing Techniques that are 
already have to be migrated.  I don't think we can require research 
behind that.
01[10:02] <jeanne> JF: That's work that is already happening in AGWG.  
All the things we are discussing already are done.
01[10:03] <jeanne> Shawn: We strive to make informed decisions. When in 
doubt, see design principle 1.
[10:03] <Cyborg> +1 to when in doubt, see design principle 1
[10:04] <Cyborg> can we repost link we are working from? thanks
[10:04] <Lauriat> 9. Write the guidance so it can be used in adaptable 
and customizable ways.
01[10:04] <jeanne> Topic: Design Principle 9
[10:04] <Lauriat> Requirements draft: 
https://w3c.github.io/silver/requirements/
[10:04] <JF> Q+ to comment on the last new principle (#10)
[10:05] <Lauriat> 
https://www.w3.org/2002/09/wbs/35422/SilverRequirmentsReview/results
01[10:06] <jeanne> 9. Write the guidance so it can be used in adaptable 
and customizable ways.
01[10:06] <jeanne> Shawn: How does that differ from requirements we 
already have: Flexible structure and multiple ways to display.
[10:06] <Lauriat> 3.2 Flexible structure Create a maintenance model for 
guidelines that can better meet the needs of people with emerging 
technologies and interactions.
[10:07] <Lauriat> 3.3 Multiple ways to display: Make the guidelines 
available in different accessible and usable ways so the guidance can be 
customized by and for different audiences.
[10:07] <JF> +1 to Shawn
01[10:08] <jeanne> Shawn: I remember the discussion and think it is 
covered by existing requirements
01[10:08] <jeanne> Denis: Can we go back to the original document so we 
don't lose the intent?
01[10:09] <jeanne> Charles: We wanted to insure that there was a 
technical way to ingest the content rather than copy and rewrite, such 
as pulling it into an API.
01[10:09] <jeanne> JF; Have we talked about an API as an architectural 
structure?
01[10:10] <jeanne> Shawn: We have talked about that in the Information 
Architecture
01[10:11] <jeanne> ... I don't think we want to put it in the 
requirements, but I don't want to lose the idea.  It's a little too 
specific for a Requirements.
01[10:11] <jeanne> ... We have it noted in the project plan
01[10:11] <jeanne> Jeanne: MIke Crabb built that into the IA prototype 
first
01[10:12] <jeanne> JF: Let's capture it in the Principle. I don't see a 
problem putting it down in writing.
01[10:12] <jeanne> Shawn: The Design Principles are intended to be more 
ongoing.  Having an API is too specific.
01[10:13] <jeanne> Charles: Multiple ways to Display doesn't just mean 
our end of a W3C-published document, but that the user can extract the 
data and display it as well.
01[10:14] <jeanne> SHawn: I think we should add Charles thought to 
Multiple Ways to Display to capture John's concern.
01[10:15] <jeanne> JF: But that is too strict to be a requirement
01[10:16] <jeanne> Shawn: I don't think we need to explicitly call it 
out in the Requirements doc.
[10:16] <Lauriat> Project plan draft with Information Architecture 
calling out API design: 
https://docs.google.com/document/d/1zFgVcDUMSOrZ5nnGRocs2pZYkqOhwdyMU_Z62_CedbQ/edit#heading=h.u2yznko9x31q
[10:16] <JF> ack (#
01[10:17] <jeanne> Denis: The principle was similar to the 
Requirements. What is the difference between Requirements and Principles 
in this document?
01[10:17] <jeanne> ... can we define what the difference is between 
them so we can see if they need to be in both places?
01[10:18] <jeanne> Shawn: You aren't the only person with that 
question.  It isn't a problem to be in both places.  The difference is 
that Requirements are measurable when we go to Candidate Recommendation
01[10:19] <jeanne> ... the Design Principles are important concepts 
that we want to do, but aren't as measurable.
[10:19] <CharlesHall> design principles = decision making framework
01[10:19] <jeanne> ... they should guide, shape and steer decisions 
about how we make this work.
[10:19] <JF> +1 Charles
01[10:19] <jeanne> +1 Charles
01[10:20] <jeanne> Denis: We should explain that specifically in the 
document
[10:20] <dboudreau> +1 Charles as well
01[10:20] <jeanne> action: jeanne to draft paragraph to explain the 
difference.
[10:20] <trackbot> Created ACTION-200 - Draft paragraph to explain the 
difference. [on Jeanne F Spellman - due 2019-04-02].
01[10:23] <jeanne> Shawn: What should we do with this design principle? 
Delete or merge it into Requirements?
01[10:23] <jeanne> JF: I think the principle supports the Requirement.  
I don't have a problem with redundancy.
01[10:23] <jeanne> Denis: I don't see it as a problem, it reinforces it.
01[10:24] <jeanne> RESOLUTION: Accept it as is, adjust the wording to 
account for an API.
[10:24] <Lauriat> 10. Include the ability to support automated testing 
when possible and provide a method for repeatable test results when 
manual testing is required.
01[10:24] <jeanne> Topic: DP 10
01[10:25] <jeanne> Include the ability to support automated testing 
when possible and provide a method for repeatable test results when 
manual testing is required.
01[10:25] <jeanne> JF: This principle and the discussion around this 
idea is the biggest hill yet to climb.  This speaks to the conformance 
model.
01[10:25] <jeanne> ... This is a critical requirements
01[10:27] <jeanne> Jeanne: Is it measurable? That's why we put it in 
Design PRinciple.
01[10:27] <jeanne> JF: It's true false.
01[10:27] <jeanne> Shawn: But does WCAG 2.1 meet this requirement?
[10:28] <Lauriat> How about "1.3.1 Information, structure, and 
relationships conveyed through presentation can be programmatically 
determined or are available in text."
01[10:28] <jeanne> JF: It's a little handy-wavey
01[10:29] <jeanne> Shawn: I can use 1.3.1 to justify any DOM structure 
I want.
[10:29] <bruce_bailey> q+ to ask for another example besides 1.3.1
01[10:29] <jeanne> JF: 1.3.1 became the junk drawer in the kitchen.
[10:30] <dboudreau> Every single SC can be measured for pass/fail when 
you break them down to a more granular level
01[10:30] <jeanne> JF: This conversation could last for a few weeks.
01[10:32] <jeanne> ... the conformance model is still not done.
01[10:33] <jeanne> Jeanne: But the measurability part of the 
conformance model is set and we know how we wnat to do it. The scoring 
part of the COnformance model is what is not yet complete.  We know we 
are going to do measurability.