W3C

- DRAFT -

Silver Task Force & Community Group

11 Dec 2020

Attendees

Present
jeanne, JF, sajkaj, Lauriat, Chuck_, SuzanneTaylor, PeterKorn, AngelaAccessForAll, shari, KimD, Jan, Jemma
Regrets
Todd, Bruce
Chair
Shawn, jeanne
Scribe
ChrisLoiselle

Contents


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

review holiday schedule & any subgroup schedule announcements

update on publishing status

Chuck: We are actively engaged in working through the issues to resolve.

Jeanne: Any questions or comments for Chuck?

Continue the Requirements issues

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

<jeanne> https://docs.google.com/document/d/1iTlQhPQfHKZcWlLI7f8BHRoTIBUdLdHRhSjzXwplk2A/edit#heading=h.tcr49p9f59ry

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.

Design PRinciple 5

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

Continue the Requirements issues

Any updates from subgroups or requests for agenda spots

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

Summary of Action Items

Summary of Resolutions

  1. 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.
  2. 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.
  3. 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.]
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/12/11 19:51:09 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]