Silver Task Force & Community Group

04 Sep 2020


jeanne, MichaelC, CharlesHall, Grady_Thompson, KimD, sajkaj, Francis_Storr, mattg, shari, Crispy, PeterKorn, AngelaAccessForAll, Jan
Shawn, Bruce


<ChrisLoiselle__> my irc doesn't seem to be working fully....I'll scribe next time. Sorry!

<jeanne> scribe: sajkaj

<scribe> scribe:sajkaj

review updated Editor's Draft

js: Asks rm and mc for update summary to Editor's Draft since Tuesday ...
... there've been quite a few edits

rm: some smaller changes ...
... additional examples; additional ed notes substantially meeting, scoring, etc

<jeanne> Editor's Draft - Main Branch <- https://w3c.github.io/silver/guidelines/

rm: also some consistency of phrasing edits
... also model simplified ...

mc: creating templates for the doc; howtos, techniques/method
... using headings as basis for howto template
... trying for look and feel consistency; but easiest to add content
... notes the template directory which should be copied; each tab a separate file
... supply content for each tab using simplest possible html
... the id's will be important to keep, of course
... would be acceptable to have working examples inside the howto;
... howto examples are not code; manager level
... believe the template is good and now porting content to test whether it actually works
... method template will be next; not yet started

js: notes we're not requiring groups to fill in code
... like the idea of embedding media! xr examples, videos, etc

mc: every howto is its own folder, so easy to add things

<Zakim> jeanne, you wanted to say that we aren't expecting the groups to do it. We can copy from Google Docs

review consistency spreadsheet

js: taking up some substantive comments from Tuesday deep dive ...
... testing each funct outcome a la Jake's suggestion
... still working on it, the solution we came up with not run by Jake yet
... Sarah noted lack of consistency
... Sarah has been working toward consistency

<Rachael> https://docs.google.com/spreadsheets/d/1_Vu0ix-d-Qrv1wDZYQhfUX6jICE_bRalypp1rtcie8w/edit#gid=1109648765

<jeanne> https://drive.google.com/drive/folders/15u5P_VwQUu--1NXSzu2Wwsj-QalDCt_W

rm: working toward tentative decisio resolution ...
... guidelines top level org struct; what we need to do
... tied to guidelines are howto

sj: Yeah!

rm: funct outcomes now just outcomes and will have people centered descripts
... below outcomes are techniques; previously called methods
... keeping the same term as 2.x
... no need to switch term, even though the functionality a bit different
... techniques used to score functional outcome

js: one to many guidelines and outcomes

pk: asks would be helpful to have high level goals or purpose statement
... believe high level goal is making the web accessible; should we articulate that?

<jeanne> https://w3c.github.io/silver/guidelines/#key-requirements

js: believe the intent in the above uri, if insufficient -- please add content suggestion

mc: support more info in intro
... also expect we may add methodology section

pk: my thought was to put it in intro

ch: we're already changing meaning of guideline; concerned to change meaning of techniques only compounds confusion
... would agree with the change if the meaning was the same, but it isn't
... how we describe outcomes will include "who it benefits" statement; could be n functional needs

<jeanne> Consistency spreadsheet <- https://docs.google.com/spreadsheets/d/1_Vu0ix-d-Qrv1wDZYQhfUX6jICE_bRalypp1rtcie8w/

rm: looks at the new attempt at better consistency ...
... proposed struct for how to write a guideline
... outcome name is the starting point there; the results statement
... ex with techniques: if two ways to solve, becomes two techniques
... text alternatives will have several depending on object

ch: curious whether exception -- have concern -- tie to who it benefits
... would like to see the linkage between qui bono and technique

rm: may be reason to split into multiple outcomes

ch: that would still require the many to many relationship

js: outcomes have .and. struct; one needs x .and. y .and. z ...
... semantic styling that suggests technique is the .or. logic; this way .or . that
... the .or. list should benefit the same group

ch: so headings is not one outcome because doesn't map to people who don't see
... so headings would have three outcomes

js: believe that keeps the who it serves grouping consistent
... we need to do more to be sure

rm: notes may be multiple techniques within a view

mc: not sure how to express that clearly but believe it's correct

<jeanne> Change the name Method to Technique

-1 agree with ch

<CharlesHall> -1

<jeanne> +1

<Jan> +1

<Rachael> +1

<KimD> 0 (not sure)

<AngelaAccessForAll> +1

<Crispy> +1

<Francis_Storr> +1

<jeanne> USe the term "Method"


<jeanne> 0

<PeterKorn> Can I vote "0" for "I don't feel strongly either way"?

<Rachael> 0

<Grady_Thompson> 0

<Jan> 0

<Crispy> 0

<KimD> 0

<Francis_Storr> 0

<CharlesHall> +1

<AngelaAccessForAll> +1

<jeanne> Use the term TEchnique


<Rachael> +1

<CharlesHall> -1

<jeanne> +1

<Jan> +1

<shari> +1

<AngelaAccessForAll> Pardon! +1

<Crispy> +1

<KimD> -.5

<PeterKorn> 0

<CharlesHall> and we are already doing that with the term Guideline

<ChrisLoiselle__> 0, if I'm following we are saying Techniques: instructions on how to follow methods in specific technologies and then we talk to Methods: detailed techniques and tests for rating how well a functional outcome for a technology has been met.

js: proposes we use method for now and ask whether people would prefer technique

RESOLUTION: We will stay with "method" rather than moving to "technique" to avoid confusion with the different meaning from 2.x

<jeanne> To accept the Consistency work from the spreadsheet

<CharlesHall> +1 as described

<Jan> +1

<Rachael> Consistency work includes: And/Or distinction between outcome name and method name and proposed formats for various labels.

<KimD> +1 as described

<Rachael> +1

<jeanne> +1

<shari> +1


<CharlesHall> +1

<Grady_Thompson> +1

<Francis_Storr> +1

<Crispy> +1

<CharlesHall> and the EN 301 549 has “functional performance statements”

RESOLUTION: Adopt the proposed changes for consistency including And/Or distinction between outcome name and method name and proposed formats for various labels.

<jeanne> Changing the term Functional Outcome to Outcome

<CharlesHall> +1

<AngelaAccessForAll> +1


<Francis_Storr> +1

<Grady_Thompson> +1

<Crispy> +1

<KimD> +1

<jeanne> +1

<mattg> +1

<Jan> +1

<Rachael> +1

<shari> +1

RESOLUTION: Change "Functional Outcome" to "Outcome"

<jeanne> the approach of an exception method to address proprietary, emerging tech, or Methods not yet developed

mc: a bit concerned that it seems like failure method -- would rather handle exceptions differently, not sure how yet

<CharlesHall> not a fan of the word ‘exception’ specifically because i advocate not embracing the exceptions within the SC of 2.x.

mc: in favor of exception somewhere, not sure method is where

rm: like it in method; to avoid repeating fields in method

<CharlesHall> +1 to at method level, but hopefully a different word

rm: think exception is wrong word, though
... but agree "generic" is a problem, too

<KimD> I also don't like the word "exception"

rm: recalls one way to show is provide results of testing with pwds

mc: support that as an option; but shouldn't be the only way

<Rachael> It's long but maybe "Emerging/Proprietary/Other"

mc: recalls we intended to stay on top of emerging tech in 2.x; not sure we'll do better
... need to leave room for techniques we haven't documented

<PeterKorn> Are you saying people are taking exception to that word?

mc: exceptions not to the technique; but to the outcome
... if your lang doesn't support this feature, you don't have to do it

rm: yes, that is not the intent here.

<Jan> I have to drop for another call. Have a great weekend everyone! :-)

[discussion of terminology options]

<CharlesHall> i thought the exception was for the outcome based on audience. exception is for the technology? but not if technology agnostic?

mc: we're looking for a word that says "we didn't document it"
... could live with other

rm: define in glossary!\

<jeanne> +1 to Fallback

<KimD> Works for me

<CharlesHall> fallback implies graceful degradation which is the sad opposite of progressive enhancement

<Crispy> +1 to Fallback

<Rachael> +1 to Fallback


<CharlesHall> -1

<KimD> +1 to fallback

<AngelaAccessForAll> 0

<Grady_Thompson> 0

<Francis_Storr> +1

<AngelaAccessForAll> (undecided)

<jeanne> To be continued on Tuesday

Summary of Action Items

Summary of Resolutions

  1. We will stay with "method" rather than moving to "technique" to avoid confusion with the different meaning from 2.x
  2. Adopt the proposed changes for consistency including And/Or distinction between outcome name and method name and proposed formats for various labels.
  3. Change "Functional Outcome" to "Outcome"
[End of minutes]

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

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)

Present: jeanne MichaelC CharlesHall Grady_Thompson KimD sajkaj Francis_Storr mattg shari Crispy PeterKorn AngelaAccessForAll Jan
Regrets: Shawn Bruce
Found Scribe: sajkaj
Inferring ScribeNick: sajkaj
Found Scribe: sajkaj
Inferring ScribeNick: sajkaj

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]