W3C

- DRAFT -

Silver Community Group Teleconference

21 May 2019

Attendees

Present
dboudreau, Chuck, AngelaAccessForAll, Cyborg, KimD, bruce_bailey, CharlesHall
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Chuck

Contents


<Lauriat> Where we left off in the migration doc: https://docs.google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/edit#heading=h.hmkps7j17nyg

<Lauriat> https://www.w3.org/TR/WCAG21/#labels-or-instructions

<Cyborg> sorry just arrived, if there are links, please repost, thanks.

[07:34] <Lauriat> Where we left off in the migration doc: https://docs.google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/edit#heading=h.hmkps7j17nyg [07:34] <Chuck> present+ [07:35] <Lauriat> https://www.w3.org/TR/WCAG21/#labels-or-instructions

For Kim and others who just joined, here are the links:

[07:34] <Lauriat> Where we left off in the migration doc: https://docs.google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/edit#heading=h.hmkps7j17nyg [07:34] <Chuck> present+ [07:35] <Lauriat> https://www.w3.org/TR/WCAG21/#labels-or-instructions

<scribe> scribe: Chuck

<dboudreau> how about adding "sufficient labels for form field elements are provided for all users (sighted and non-sighted)" to the 3.3.2 grouping?

Denis: Need to add some things to 3.3.2.
... Something that leads us to understanding that label is expected to be perceivable and programatically determinable.

Shawn: Chuck MUTE!!!!

Denis: John follows same protocol. We have internal interpretation. 3 main aspects of 3.3.2. Naturally emerge: Missing label...
... Should they be reflected in methods?
... Visible label is not part of what we have right now.

Shawn: I'll add as a note.

Denis: When you look at sc itself, you don't see anything about visible label, but when you look in the definition, you derive "visible".

Shawn: Thanks!
... 3.3.3 Error Suggestion
... <reads>
... We'll need to pick this one apart.
... We have a couple of if's. IF an input error is automatally detected.

Charles: Similar to 3.3.1. If you detect an error, report an error. 3.3.3 is if you know how to remedy it, present how to remedy to user.

Shawn: Agree.
... Adding another method...
... <reads>

Denis: timely and accessible manner?

Shawn: That can be presumed for everything.

Denis: OK.

Shawn: We can discard exceptions since we will revisit.
... <reads exceptions>

Jeanne: Security exception would be global.

Shawn: I think you are right.

Charles: Is "known" sufficient?

Shawn: And automatically detected. Not whether or not it's possible. If you provide no form validation then you are technically passing.

<dboudreau> https://www.w3.org/TR/WCAG21/#error-suggestion

Charles: Known implies that a human knows, like an author, as opposed to the system automatically detecting. Like an email address without the @ sign.

Denis: Anything more specific, like formats, or a range. Or numbers vs. letters. Is that too granular?

Chuck: I think so.

Shawn: Probably yes.
... We'll go through again and write the user need. As a part of that process we'll shift some things around some more.

Denis: OK.

Shawn: Next seems related... error prevention.
... Error prevention, legal financial data.
... <reads>

<dboudreau> Proposal to summarize 3.3.4: If the user can change or delete legal, financial, student exam responses, or unrecoverable/unintentionally modified or deleted data, the changes/deletions must be reversible, verified, or confirmed.

Shawn: Seems to cover everything in the world.

Charles: Legal and financial seems limited.

<bruce_bailey> agreed, seems to cover everything

Jeanne: The way its written makes it very expensive to test. You need a human to evaluate the category. But after that it is probably automatically testible.
... If we said "here's the advice for everything" and took out financial and legal.

Shawn: It seems that it covers everything the user cares about.

Charles: I've always read without the "or".

Denis: We don't perceive it as something that complicated. We agree on financial and data. The 3rd is data in general.

Chuck: Example "are you sure you want to format your hard drive"?

Shawn: this breaks down to 3 separate methods.
... Reversible, checked, confirmed.

Bruce: Gmail is a good example. I click on send, it's not reversible, checked or confirmed. I emailed my boss an inappropriate joke.

Shawn: GMail offers undo so that you can reverse submisstion.

Bruce: We are happy having 3.3.4 apply everywhere all the time?
... I'm thinking in Silver it will.

Shawn: What is the fundamental intention of what this SC covers. Anybody have an example of where this doesn't apply?

Bruce: I cannot.

Chuck: I have a possible example.

<bruce_bailey> search submit is good example

Denis: Agrees with Chuck's example of google search and mentions lots of other examples.

<bruce_bailey> so is a low-impact blog post

Shawn: I'm thinking that Jeanne's comment is spot on. It may be the context and importance that makes the level of guidance... level of different methods.
... If you make something with confirmation for legal and financial, yes you need to do that. But a mechanism for something nuanced... Like a blog post, I could see the need to review.

Denis: We can expand 3.3.4 in silver, whenever you are submitting information... anything you can live with after it is submitted. Blog post not as critical as submitting ssn to govt.
... If we extend it to "anything you can live with after the fact" does exclude a few things.
... I'd be comfortable expanding "reversible". Change search would be to backtrack.

Shawn: I'm adding a comment about dismissable.

Denis: anything that's more critical, the idea that you can confirm before it's done or validate it... well.. kind of same thing.

Jeanne: I think we can change orientiation that it applies to everything, and then have an exception for "trivial".

Chuck: participated, didn't scribe.

Shawn: This will come out as we come up with user needs. Pasting Chris's comments in IRC.

<Lauriat> From Chris: From the intent of the SC User Controllable data is " data that is intended to be accessed by users". Also from intent : the intent is to prevent mass loss of data such as deleting a file or record. It is not the intent to require a confirmation for each save command or the simple creation or editing of documents, records or other data. I believe Denis mentioned blog posts submissions.

Jeanne: I don't think we can go down "completely reversible". That would be an security violation.

Shawn: <reads his paste above>

<bruce_bailey> we might be able to say "recoverable" instead of reversible

Shawn: Adding comment on the user need part of this.
... We will need to draw the line or define is scope of the intention of what we are trying to help.

<bruce_bailey> if we can exception for "trivial" -- that would be great

Jeanne: If we could get rid of human need as to whether or not it's there and how critical it is. Then we can have automated tests and it's less expensive.

Shawn: That will be very difficult. Blog post example. One thing if it's a micro blog where nobody cares, but if I'm on twitter that "something sucks", nobody cares. But if I use google access, I need to undo.
... Depends a LOT on context. Not sure we can automate that. We are also getting slightly ahead of ourselves.

Jeanne: Let's keep moving, but will be interesting to work on.

Shawn: We have 3 methods, reversible checked and confirmed. Does this make sense to merge in with error identification and error suggestion.

Denis: I don't think we should merge. Different enough.

Shawn: Moving on... 3.3.5 Context Sensitive Help is available.
... Seems a lot like labels aspect. Extended labels and instructions.

Denis: That could be combined with labels. Typically like little icon for help.

Cybele: Is that what 3.3.5 is? Or is it something to expand for task based assessment? Or to support things like reporting for accessibility statements.

Denis: Context sensitive though.
... that's key, within the context of the thing you are working on. According you can blow up, icon you can go over.

Charles: Sufficient technique is instructions at the start of form.

Jeanne: We need to look beyond web. Gaming applications where help would be considerable and sizeable.

Denis: For video game, different panel or screens...

Shawn: Various games, fairy over shoulder says something helpful. In that moment and in that place.

Denis: Not like general documentation.

Shawn: What you described is difference in delivery. Maybe you hit a button and fairy helps.

Cybele: Is intent on different guidance? Or... maybe this could expand in silver. Would that be a different type of guidance?

Charles: Opportunity to discuss help in general. I have a different interpretation of context. The method to get to help is in the context of the item.

<dboudreau> WCAG definition for context-sensitive help - help text that provides information related to the function currently being performed

Chuck: Discussion about whether or not this is on the help or how the help is delivered.

Charles: Maybe need guidance on help in general, and context sensitive help is how you get to the help.

Shawn: We will write up and uncover when we get to user needs.

Cybele: Can we flag?

Shawn: Yep.
... 10 minutes left. Last in section is 3.3.6 Error Prevention All. Seems same for previous, but muddying definition of context.
... I think we can keep same methods on this one.
... For this same as previous one.

Denis: By adding dismissable we are covering 3.3.6 automatically.

Shawn: Agreed.
... 8 minutes. We can get through all of robust.

Denis: Bold!

Jeanne: Coded correctly guidelines.

Shawn: 4.1 compatible.
... Boils down to "code it right and don't break anything"
... Linking to overall guideline.

Denis: Combining 4.1.1 and 4.1.2 in a single guideline?

Shawn: Yes.
... All part of "code it correctly".

Denis: I'm looking at what has been done up to this point. You weren't doing that for other principals.

Shawn: Point taken, doing SC's same way we did before.

Denis: I think 4.1.1 and 4.1.2 will be very different.

Shawn: I would personally not have robust anyways.

Charles: Still some challenges with user agents ability to parse closing tags.

Shawn: I've restated 4.1.1 to "use valid markup".
... I think that's the overall intent.

Denis: I'd be more specific. Complete start and ending tags, duplicate attributes.

Shawn: I'm thinking we don't need to be that specific because other things in html specifications that affect layout. By listing here you imply you don't have to do the other things.

Denis: Technically you don't have to.

Shawn: That's my point.

Chuck: TIME CHECK!

Jeanne+

Jan-

Jeanne: Jan is having a grand baby!

<bruce_bailey> congrats to Jan!

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: 2019/05/21 14:31:14 $

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: dboudreau Chuck AngelaAccessForAll Cyborg KimD bruce_bailey CharlesHall
Found Scribe: Chuck
Inferring ScribeNick: Chuck

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 21 May 2019
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]