Minutes of Silver meeting 15 February 2019

Formatted minutes <https://www.w3.org/2019/02/15-silver-minutes.html>

Text of minutes:

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                 Silver Community Group Teleconference

15 Feb 2019

Attendees

   Present
          johnkirkwood, Charles, LuisG, JF, KimD, jeanne,
          kirkwood, Cyborg, mikeCrabb, Shawn, Lauriat,
          AngelaAccessForAll, Makoto, JanMcSorley, Jennison,
          bruce_bailey, shari

   Regrets

   Chair
          jeanne, Shawn

   Scribe
          bruce_bailey

Contents

     * [2]Topics
         1. [3]Requirements
            https://w3c.github.io/silver/requirements/index.html
            work
         2. [4]Technology Neutral
         3. [5]New Requirements
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

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

      [8] https://w3c.github.io/silver/requirements/index.html

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

      [9] https://w3c.github.io/silver/requirements/index.html

Technology Neutral

   <jeanne>
   [10]https://lists.w3.org/Archives/Public/public-silver/2019Feb/
   0014.html

     [10]
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

   [11]https://w3c.github.io/silver/requirements/index.html#oppotu
   nities_usability

     [11]
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
   [12]https://www.plainlanguage.gov/

     [12] 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

Summary of Action Items

Summary of Resolutions

   [End of minutes]