<jeanne> https://w3c.github.io/silver/requirements/index.html
<jeanne> https://lists.w3.org/Archives/Public/public-silver/2019Feb/0014.html
<Lauriat> Technology Neutral Separate the text description of the guideline from the technical platform (such as HTML, CSS) so that the purpose of the guideline is understandable by a non-technical audience. The technical guidance is easily displayed, but is not essential to understanding the guideline. This also gives the ability to apply the guidelines to emerging technology, even if the technical advice does not yet exist.
<jeanne> Shawn: It says more about how to do it, rather what it is that we want Technology Neutral to mean.
+1 that this is how and not what
<KimD> +1 as how and I like it
<jeanne> Guidelines must be applicable across multiple platforms.
<jeanne> Guidelines must be worded so they are applicable across multiple platforms and are clearly understood by a non-technical audience. The technical detail is easily available, but it not required to understand the guideline. Technology neutral guidelines give the ability to apply the guideline to emerging technology, even if the technical advice does not yet exist.
<jeanne> Guidelines must be worded so they are applicable across multiple technologies and are clearly understood by a non-technical audience. The technical detail is easily available, but it not required to understand the guideline. Technology neutral guidelines give the ability to apply the guideline to emerging technology, even if the technical advice does not yet exist.
<Zakim> bruce_bailey, you wanted to ask about requirement about non-technical audience. Do we not already have the requirement for plain language?
<Lauriat> New draft: Guidelines must be worded so they can be applicable across multiple technologies. The technical detail is easily available, but it not required to understand the guideline. Technology neutral guidelines give the ability to apply the guideline to current and emerging technology, even if the technical advice does not yet exist.
From WCAG 2.0:
WCAG 2.0 success criteria are written as testable statements that are not technology-specific.
<Lauriat> Usability aspect to go into its own requirement.
So silver could be:
Silver Guidelines are not technology-specific.
+1 to Shawns draft
<Charles> +1
<KimD> +1 to Shawn's draft
<AngelaAccessForAll> Could we word it slightly different like this?: Guidelines must be worded so they can apply to multiple technologies. The technical detail is easily available, but isn't required to understand the guideline. Technology neutral guidelines give the ability to apply guidelines to current and emerging technology, even if the technical advice doesn't exist yet.
<AngelaAccessForAll> oops--I may have mistyped!
+1 to Angel's
<Lauriat> +1 to Angela's edit with a tweaked last sentence.
s/angel's/angela
<jeanne> Proposed from earlier discussion: Guidelines are worded so they are understandable by a non-technical audience.
<scribe> scribe:bruce_bailey
<Lauriat> Readable: When guidelines are easier to read and understand, users – especially people in the development cycle who are less technical – are more likely to implement accessibility. When all audiences are considered in the language and terminology used in the guidelines, the likelihood increases that they will:
<Lauriat> reach a larger audience; be better understood; be easier to translate; be interpreted as easier to implement
Shawn: we will want to move or copy opportunities into requirements
four points
https://w3c.github.io/silver/requirements/index.html#oppotunities_usability
Need to add goal for useabiltiy or readability
Charles: not all opportunites can be written as requirements
Shawn: agreed, measure of success is around our using plain writing
the increased uptake of Silver remains as an opportunity, but not requirement for Silver guidelines
Shawn: working to set scope of useability/readability
Jeanne: example is we want it to be easy to find information, but is that a Silver requirement?
Shawn: Example could be composing text using plain language
other aspect is simple structure
structure of silver overall should be easier
Jeanne: Research result is that we need to make it easier to find information.
<Lauriat> readability of written word; simple structure of written word; simple structure of Silver
<Charles> so the sentiment for making usability a requirement is: the guideline content and presentation should be more usable, and more understandable through simple language?
Shawn: these are 3 aspects of
useability we can have as requirement for silver
... are there more we could add as requirements for silver
itself?
Jeanne: Challenge is that we cannot always use simple language in the methods.
Shawn: Simple langue is a how, not a requirement for silver.
Charles: understandable by non-technical audience is very close to a requirement for plain language
<jeanne> The Guidelines are understandable to a non-technical user
<AngelaAccessForAll> +1 to Charles
<jeanne> he Guidelines are understandable to a non-technical audience
Charles: I would like the requirement for Silver to use simple language
John Kirkwood: plain language would be a good thing to require
<Lauriat> Potential draft for usability that just removed the last bit, which I think lessens the point of it: The guideline content and presentation should be more usable and more understandable.
Sheri: seconds the requirement for plain language
<johnkirkwood> both!
<KimD> +1 to both
Bruce: Understandable to a non-technical user is something that we can say we have succeed or not
<AngelaAccessForAll> +1 to both
Bruce: +1 to what shawn said
<johnkirkwood> possible a good reference https://www.plainlanguage.gov/
Shawn proposes language that incorporates both ideas
<Lauriat> The top-level guidelines should be understandable by non-technical audience. All guideline content and presentation should be more usable, and more understandable through simple language.
Jeanne: good but strike "more"
<Lauriat> Removing "more": The top-level guidelines should be understandable by non-technical audience. All guideline content and presentation should be usable, and understandable through simple language.
<AngelaAccessForAll> +1
JF: works without the more
<Charles> +1
word smithing continues...
<AngelaAccessForAll> +1 to John
JF: The guidelines should be understandable by non-technical audience. All text and presentation should be usable and understandable through the use of simple language.
<Lauriat> New new new draft: The guidelines should be understandable by non-technical audience. All guideline content and presentation should be usable and understandable through the use of simple language.
<JF> +1
<Lauriat> +1
bruce: +1
<Lauriat> "Readability/Usability"
Shawn: Draft heading needs feedback?
Bruce asks if this is 3.5 under requirements. Shawn: Yes.
<AngelaAccessForAll> +1 to the heading
<johnkirkwood> +1
Bruce: +1 to keep heading
<KimD> +1
Shawn: Take quick look at other opportunities
Can some other be converted to requirements?
First two we already have.
<johnkirkwood> findable?
The "on ramp" is a bit more abstract / hard to measure
Jeanne: AGWA asked that we check to include more from GOGA task force
Is that something we could include?
<Lauriat> Multiple ways to measure: Different guidance has potential for different measurement beyond a simple true false success criterion so that more needs of people with disabilities can be included.
<Lauriat> Flexible structure: Create a structure for guidelines that can better meet the needs of people in unanticipated technologies and interactions.
Shawn: We have two good examples of addressing challenge
<johnkirkwood> structure? modality?
Shawn: we have end state that has meassure for more people
Charles: overlapping opportunity around participation
sentiment is for transparency and out in the open
we could have flexible participation as a requirement in the guidelines
Shawn: likes sentiment and has
that idea in design principles
... that guides how we work, but might be hard to measure in
big R requirments final product
<johnkirkwood> +1 to usability
<KimD> +1 to "findable" (via tagging?)
<Lauriat> 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) FAILED: s/angel's/angela/ Succeeded: s/requiremnet/requirement/ Default Present: johnkirkwood, Charles, LuisG, JF, KimD, jeanne, kirkwood, Cyborg, mikeCrabb, Shawn, Lauriat, AngelaAccessForAll, Makoto, JanMcSorley, Jennison, bruce_bailey, shari, RedRoxProjects Present: johnkirkwood Charles LuisG JF KimD jeanne kirkwood Cyborg mikeCrabb Shawn Lauriat AngelaAccessForAll Makoto JanMcSorley Jennison bruce_bailey shari Found Scribe: bruce_bailey Inferring ScribeNick: bruce_bailey Found Date: 15 Feb 2019 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]