W3C

- DRAFT -

Silver Conformance Subgroup

17 Mar 2020

Attendees

Present
jeanne, sajkaj, PeterKorn, Chuck, joecronin, AngelaAccessForAll, KimD
Regrets
Chair
jeanne
Scribe
sajkaj

Contents


<Chuck> https://www.w3.org/WAI/GL/wiki/Upcoming_agendas#Mar_24th

<scribe> scribe: sajkaj

<jeanne> http://john.foliot.ca/demos/HeadingsTestOne.html

js: Notes discussion in today's earlier Silver call took up item from virtual F2F
... Issue is partial credit and how to account for them
... All with impact on performance and scoring

<jeanne> https://raw.githack.com/w3c/silver/ED-changes-25Feb-js/guidelines/explainers/SectionHeading.html#tab5

<jeanne> https://raw.githack.com/w3c/silver/ED-changes-25Feb-js/guidelines/methods/template.html#tab4

js: So should these be in guidelines? Methods? or Testing?
... Discussion this morning re Testing using Headings draft doc

<jeanne> https://docs.google.com/document/d/1TgFWsggRNiUYU_N9GPCvU1KUhexiRWjYTelTKZPMAOE/edit#heading=h.9evrlc9tm9cl

js: While I started afresh this morning, SL noted much was repetitive of earlier work and we should not reinvent
... Q-- What have we? Where do we put it? How do we structure it?

pk: Notes some functional criteria, with/without vision, vs limited vision / use of speech
... Might be limited or no perception of color
... So to base on where strategy changes
... e.g. where captions might be appropriate solutions
... Notes addressing limited hearing is not yet well described
... Believe bears more studyand we should return to it

js: That's why I think we should go on list with this

kd: Believe we suggested just listing for now then looking for overlaps

pk: Heads Up: May soon be distinction between limited vocal capability vs none
... Example would be als or stroke where speech isn't intelligible, but emerging AT that can provide a bridge, perhaps driving speech interface
... The tech will understand the utterances
... Asks whether we've compared these to the 13 in CVAA

js: Requests link?
... Worry about building functional needs into structure in a way that makes them difficult to update

<PeterKorn> -Operable without vision -Operable with low vision and limited or no hearing -Operable with little or no color perception -Operable without hearing -Operable with limited manual dexterity -Operable with limited reach or strength -Operable without time-dependent controls -Operable without speech -Operable with limited cognitive skills

js: It makes our tests more real world and less hypothetical

[pk pastes CVAA text into doc]

[js reviews identified criteria]

js: Suggests we look at nav by headings only without sight

pk: Can we verify browser plugin will do that? Should we document that?

jc: Confirms

js: Maybe. Not writing the doc just yet, but identifying the info we need to writeit up so maybe so
... Also AT (screen readers)
... Asks whether we need to provide step by step instructions?
... We could have a testable statement -- allowing people to create their own tests but meet the requirement

ca: Are we sure we want to list specific plugins, AT, etc? Sounds like that could change quickly and turn into a maintanance nightmare

js: But it is data -- athought expiriment

ca: OK. No problem!

js: Asks for volunteer to write a testable statement for headings

jc: Sees some ...

<jeanne> https://act-rules.github.io/rules/b49b2e

jc: Believe heading has accessible name is better because it's parsable
... pulls from dom

<joecronin> https://act-rules.github.io/rules/ffd0e9

js: Notes complexity in the rule -- Do we want it all?
... Or just some of it?
... Is one of these the testable statement? Anyone know?

jc: Do we have testable statement definition?

js: Like expectation ...
... The nice part of testable statements is that it allows different ways to test
... Our provided test cases them become examples only

<Chuck> from this link https://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050208.html

<Chuck> comes this definition

<Chuck> [Definition: Testable Statement: An assertion of the proper application of a technique that can be evaluated as either passed or failed.]

<joecronin> https://www.w3.org/WAI/WCAG21/Techniques/html/H42

<joecronin> from the description: A screen reader can recognize the code and announce the text as a heading with its level, beep or provide some other auditory indicator. Screen readers are also able to navigate heading markup which can be an effective way for screen reader users to more quickly find the content of interest.

pk: Might we include text to guide where these are more important vs less important?

<KimD> Same as Chuck, but to the Definitions sectoin: https://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050208.html#defs

pk: Can we include where this is critical vs not such a big deal

js: To whom?
... Perhaps in the work flow? We could do that
... Images in the footer not as critical as navigation

pk: Believe this would trigger useful conversations
... e.g. a page with a few paragraphs and two headings each of which is h1 or one of which is h2

sj: Believe COGA is telling us this is OK unless first heading is H2
... Wonders about how close to mainstream some of this might be; and thus perhaps revisiting remediation in the browser for mashups

js: Likes documenting criticality in various work flows

pk: Her's what, here's where ... Believe where may be more important

js: Yes, what will vary by pwd group
... Criticality is generally appreciated particularly for COGA

pk: Even wonder about putting in edge cases, e.g. the silent movie doesn't need captions
... May have unexpected use cases

js: We have both edge cases and exceptions
... Proposes to return to this Friday

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/03/17 23:59:56 $

Scribe.perl diagnostic output

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

Present: jeanne sajkaj PeterKorn Chuck joecronin AngelaAccessForAll KimD
Found Scribe: sajkaj
Inferring ScribeNick: sajkaj

WARNING: No "Topic:" lines found.


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: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


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]