<sajkaj> resent+
<scribe> scribe:ChrisLoiselle
Jeanne: Holiday schedule availability . Last meeting if Friday the 18th. Next meeting is January 5th. Subgroups schedule is up to their own decision.
<jeanne> https://lists.w3.org/Archives/Public/public-silver/2020Dec/0028.html
Janina: Exploring conformance options subgroup will meet January 7th.
<Chuck_> Chris: Meeting 17th dec, will skip 2 weeks after and meet next 7th of Jan.
<Chuck_> Jeanne: Did you ever connect with the gentleman that wanted to participate?
<Chuck_> Chris: Yes, I invited this individual to the group, on 17th call.
Chuck: We are actively engaged in working through the issues to resolve.
Jeanne: Any questions or comments for Chuck?
Jeanne: We would like to publish requirements with wcag 3. We are working through GitHub issues.
<jeanne> Github issues https://github.com/w3c/silver/issues?q=is%3Aissue+is%3Aopen+label%3ARequirements
We are currently working on issue 186
<jeanne> https://github.com/w3c/silver/issues/186
We've worked through 3 of the issues, we are working on 4th. Jeanne pastes in Google doc.
This is about introduction material on evolving technology.
<jeanne> Evolving Technology: Silver needs a flexible design that can be updated as assistive technologies adapt and emergent technologies produce new barriers for people with disabilities. As content technology evolves, it must be re-evaluated against assistive technology for compatibility. Likewise, as assistive technology evolves or emerges, it must be evaluated against the backward compatibility
<jeanne> of various content technology.
Jeanne: Pastes in answer proposal to #4 within issue 186
<Chuck_> +1 to recollection
Shawn: Rather than adding to list of examples, we would not list things out.
<jeanne> Silver needs a flexible design that can be updated as new barriers aris from assistive technologies adaptations or emergent technologies
Janina: Do we want to say barriers and opportunities?
<jeanne> Silver needs a flexible design that can be updated as new barriers arise from assistive technology adaptations or emergent technologies.
Shawn: Plus one to that.
... On topic of conformance to silver 2020 vs. what is the
state of things, in terms of emerging technology.
... We want to make sure that the content is not dated and is
flexible to emerging tech.
<SuzanneTaylor> +1 to adding "opportunities"
Chuck: Adding on to what Janina said on opportunities
Jeanne: Plus to Janina's point as well.
Shawn: Phrasing should be included it in the first or mirroring it. We need to go beyond regression testing.
JF: Why would presume it wouldn't work in 2025 if it works in 2020? What would that have to do with emerging tech ?
Jeanne: This is not a requirement it is an opportunity . We want to keep the idea that changing technology introduces new barriers.
JF: Talks to backwards compatibility and merging the phrasing in acknowledgement of forward and backward compatibility.
+1 to JF's idea.
<Chuck_> as content technology and assistive technology evolves, we need to evaluate and re-evaluate for forward and backward compatibility.
Janina: Talks to grammar changes in phrasing ..and vs. or
<jeanne> Evolving Technology: Silver needs a flexible design that can be updated as assistive technologies adapt and emergent technologies produce new barriers or opportunities for people with disabilities. As content technology or assistive technology evolves, we need to evaluate and re-evaluate for forward and backward compatibility.
<jeanne> Evolving Technology: Silver needs a flexible design that can be updated as assistive technologies adapt and emergent technologies produce new barriers or opportunities for people with disabilities. As content technology or assistive technology evolves, we need to re-evaluate for forward and backward compatibility.
Janina: Re-evaluate works . JF: Evaluate includes re-evaluate.
<jeanne> Evolving Technology: Silver needs a flexible design that can be updated as assistive technologies adapt and emergent technologies produce new barriers or opportunities for people with disabilities. As content technology or assistive technology evolves, we need to re-evaluate for forward and backward compatibility.
<sajkaj> +1
<shari> +1
<PeterKorn> +1
<SuzanneTaylor> +1
<jeanne> +1
<JF> +1
<Lauriat> +1
Jeanne: Can we get plus ones on this?
<Jan> +1
+1
<Chuck_> +1
<KimD> +1
RESOLUTION: Update Opportunities 2.3 Maintenance as amended: Evolving Technology: Silver needs a flexible design that can be updated as assistive technologies adapt and emergent technologies produce new barriers or opportunities for people with disabilities. As content technology or assistive technology evolves, we need to re-evaluate for forward and backward compatibility.
RESOLUTION: Update Opportunities 2.3 Maintenance as amended: Evolving Technology: Silver needs a flexible design that can be updated as assistive technologies adapt and emergent technologies produce new barriers or opportunities for people with disabilities. As content technology or assistive technology evolves, we need to re-evaluate for forward and backward compatibility.
<jeanne> Design Principle 5: Be written in plain language, as easy as possible to understand. EDNOTE: We need a definition of plain language that includes the ease of translation. Ideally, it will be a broadly accepted definition internationally.
Jeanne: Design principle # 5 is next topic. Plain Language discussion.
<JF> would we consider referencing this: https://www.iso.org/standard/78907.html
Jeanne: Reads Design Principle 5 - Plain Language: from https://docs.google.com/document/d/1iTlQhPQfHKZcWlLI7f8BHRoTIBUdLdHRhSjzXwplk2A/edit#
<jeanne> Comment: SILVER CONTENT WILL be written in plain language SO THE INTENT AND EXPECTATIONS ARE as easy as possible to understand. PLAIN LANGUAGE REDUCES COGNITIVE AND LANGUAGE BARRIERS AND FACILITATES MULTI-STAKEHOLDER AND TEAM COMMUNICATION ABOUT ACCESSIBILITY. SILVER GUIDANCE WILL BE WRITTEN, WHEREVER POSSIBLE, FOR A DIVERSE AUDIENCE, INCLUDING THOSE NOT SPECIALIZED IN ACCESSIBILITY AND THOSE
<jeanne> WITHOUT TECHNICAL EXPERTISE.
<jeanne> Propose: Be written in plain language, as easy as possible to understand. Wherever possible, Silver guidance will be written for a diverse audience including those not specialized in accessibility and those without technical expertise.
Jeanne: Proposed text, All other design principles are a continuation of the phrase “Accessibility guidelines should” and begin with a verb. The comment is not clear language. (Not that the Requirements meets Plain Language, but we tried). I don’t know why it is scoping plain language to the intent and expectations when we want to do more.
JF: Talks to ISO standard work that is ongoing, perhaps we want to reference this on defining plain language.
PeterK: If this is something they are developing , it may not be done , in order to point to.
JF: Timing is off, but at least note moving forward.
<Lauriat> +1 to JF's intention, at least.
+1 to JF's general idea on this.
<shari> https://plainlanguagenetwork.org/plain-language/what-is-plain-language/
<jeanne> A communication is in plain language if its wording, structure, and design are so clear that the intended audience can easily find what they need, understand what they find, and use that information.
Jan: The book is translated into 22 different languages as well.
<PeterKorn> Is the text on the plain language network page itself "plain language"?
Jeanne: Main concern is internationally recognized definition.
PeterK: The current wiki almost challenges the plain language page's content. The COGA items would need to reviewed further on this before referencing.
<Zakim> JF, you wanted to comment on "Cool URLs don't change" (referencing/linking)
Janina: Refer to COGA research first.
JF: Pointing to URL may cause broken links in future for reference . May need to explore permission on persistent url, or pursue definition referenced in our document.
Janina: Is content usable defined?
Rachael: We can take a requirement to make one.
Chuck: Can we reference a definition that doesn't exist yet ?
Jan: We need a clear definition. There are many resources we need to review around plain language. We will need other resources to back up COGA research in general.
Jeanne: The issue doesn't seem to
be lack of definition it was wording changes.
... Adds editor's note that speaks to need to reach out to COGA
and developing a definition
<jeanne> 5. Be written in plain language, as easy as possible to understand. Wherever possible, Silver guidance will be written for a diverse audience including those not specialized in accessibility and those without technical expertise. [EDNOTE: We will ask for assistance from COGA in developing a definition of plain language.]
Jeanne: Can you clarify your question JF?
JF: Plain language as defined fact on a structured definition vs. general interpretation of plain language.
<Chuck_> +1 to stick to "lower case". +1 to Jeanne's proposal.
Jeanne: I think it is best to use lower case for now. Once defined, capitalized ?
JF: If it is a formal name, i.e. a thing, it would be capitalized ...for now user lower case for now.
Jeanne: We could link to definition as well.
<jeanne> 5. Be written in plain language, as easy as possible to understand. Wherever possible, Silver guidance will be written for a diverse audience including those not specialized in accessibility and those without technical expertise. [EDNOTE: We will ask for assistance from COGA in developing a definition of plain language.]
JF: I think an action item would be to move forward on this question.
<JF> +1
Jeanne: Please plus one to Jeanne's pasted proposal
<KimD> +1
+1
<sajkaj> +1
<Lauriat> +1
<AngelaAccessForAll> +1
<PeterKorn> +1
<shari> +1
<SuzanneTaylor> +1 (as long as everyone is okay that we lost the idea of ease of translation)
Janina: I believe plain language eases translation by default.
Jeanne: Do you need more than that Suzanne?
<Zakim> Chuck_, you wanted to ask does that mean we don't have to specifically call it out?
<Lauriat> +1, I think I remember Makoto making that point as well in support of plain language for that reason
<Chuck_> +1 ok to leave it out
Suzanne: I agree with that, yes. Just wanted to make sure the idea was talked to and acknowledged.
RESOLUTION: To amend Design Principle 5 as follows: 5. Be written in plain language, as easy as possible to understand. Wherever possible, Silver guidance will be written for a diverse audience including those not specialized in accessibility and those without technical expertise. [EDNOTE: We will ask for assistance from COGA in developing a definition of plain language.]
Jeanne: I believe we are in good
shape to move forward to CfC for requirement document. Is there
anything else needed?
... We will have an official request to AGWG to consider it
next week?
Rachael: +1
Chuck: +1
Jeanne: I will research dates around CfC for Tuesday's call.
<Chuck_> Chris: Visual Contrast, we added a new member to our group. Moving forward per Jeanne's intro we have invited another individual. When we meet on 17th there will be more members.
<Chuck_> Chris: It's a good development.
Jeanne: Anything else on
subgroups?
... That is , have a great weekend.
This is scribe.perl Revision of Date 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/lower case/lower case for now/ Present: jeanne JF sajkaj Lauriat Chuck_ SuzanneTaylor PeterKorn AngelaAccessForAll shari KimD Jan Jemma Regrets: Todd Bruce Found Scribe: ChrisLoiselle Inferring ScribeNick: ChrisLoiselle WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]