Requirements https://w3c.github.io/silver/requirements/index.html work

<jeanne> https://w3c.github.io/silver/requirements/index.html

Technology Neutral

<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

New Requirements

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