<AWK> +AWK
<Detlev> scribe: Detlev
<w3c> Does anyone have the webex link that they can post privately here?
<w3c> It looks like my account is still locked out from last night's issue
<w3c> oh - and btw this is Marc - not sure why it's showing "w3c"
<Chuck> yes
<Chuck> having an audio issue
<david-macdonald> http://davidmacd.com/WCAG/silver/information-relationships.html
AC: Sorry for late agenda
<alastairc> https://www.w3.org/2002/09/wbs/35422/TechniquesforApproval/results#xq19
PR was create dby David, followign a discussion at TPAC
AC: long conversation in a thread
on the PR
... looks at first glance that type would fit the SC
... but there are other instances where inputs like type=email
would be used in contexts where it is not about the user
... so in many cases type would not be good enough
... so result is to thank David and withdraw Technique
David: that's OK
AC: Most seemed happy with that result
David: Good to have had this discussion if people ask - similar discussion we had about accName as prop for purpose
mgover: Wondering if that argument also applies to autocomplete
AC: DonÄt think so because it is explicitly for the user
mgover: still doesn't seem entirely clearcut
<Zakim> bruce_bailey, you wanted to ask if we can narrow scope of technique
AC: 1.3.1 is usually not as strict - but for this particular one we need a clear signal
Bruce: can we scope it by changing the title saying it is only applicable if the page is restricted to user data?
AC: No, because there is no standardized way of signalling that restriction in scope
Bruce: Othe rTechniques also constraon application to particular cases
Jon: The idea is that the tool needs to know 100% that it is about the user, so it is not the same
mgover: you could also apply that to autocomplete
Jon: We should have a Failure for using input type on email without using autocomplete
AWK: Such a failure would not be
durable
... Failures hard to remove
Jon: People use incorrect type values like tel for credit cards
AC: Is everyone happy to decide not use this Technique (type input as sufficient technique?
AWK: We should have an addition in the Understanding doc that enshrines this decision
mgover: is autocomplete really restricted to the user, in HTML5??
<david-macdonald> https://www.w3.org/TR/html52/sec-forms.html#autofilling-form-controls-the-autocomplete-attribute
AC: I think that, yes
(people looking at HTML5 spec)
Jon: YOu can have different token values for groupings (like shipping and billing address) - so it is not quite simple - needs to be parsed by AT
AWK: Spec doesn't say it as
crisply as we would like but the gist is there
... In actual use it is not always restricted to users but in
those cases it causes problems
mgover: recollects a collateration technique of strings (?)
David: Fallback is that there is no consensus at least, s that allows us to move forward
mgover: SO we should not update the understanding text
AC: No agreement that
autocomplete is always about the user
... Any objection to withdrawing the Sufficent Technique?
RESOLUTION: Input type is not sufficient for identifying purpose, understanding document to be updated
mgover: Reason to flag Technique that the main reason was that it cannot be focused on the idividual - but the same case could be made for autocomplete so that may cause problems down the line
Brooks: Had same concerns as Michael - there is an SC that may be undermined by the lack of specificity of autocomplete
Katie: The uses of this SC have been difficult in the past - there was pushback which made us restrict it to input s
AC: Don' think the use of autocomplete undermines SC - the intention (focus on user) is clear
<Zakim> AWK, you wanted to say that this is still testable
AC: trying to expand the way it can be mwet has helped clarifying what is needed
AWK: SC is testable - what was not clear was if the ecosystem of tools would repond to this new signal
<Ryladog> My point was that I had hoped we could have scoped this SC to auto-complete only - and that the rest either needed to move the rest to Triple AAA, but there was too much pushback on that
AWK: So it i ssomewhat speculative - one can conform to it but the practical inpact we don't know yet
David: Spec is pretty clear that
it is about the user
... describles what is expected from the user
... the tokens are about the user
... felt that there may be problems with this technique
Brooks: Focus on AT, not author - that is depending on some other grouping that sets the scope
AC: No, that was why using only type is now being rejected
Jo: It is not about the user but helping the user to fill in stuff
AC: There is no means of
specifying that info is for someone else (?)
... Double values would not apply in filling in forms?
Jon: there could be a use case for that (different sets of values for self, spouse, childeren..)
<AWK> me+ Jon Avila - you give gifts to your mother in law?!? ;)
mgover: Could this variation no also be made determinable ?
JF: spouse is not a permitted
value - the list is very restricted, now part of WCAG 2.1
... then there are grouping constructs
<AWK> JF, the piece that people were struggling with is whether the HTML values are scoped just to the user like our SC
JF: but it is clear that this is
scoped just for the user
... the use case for booking holidays for family it would not
apply to family member
AC: Recounting the problem of type being nont specific to user - can the same be said about autocomplete - HTML 5 spec seems not entirely clear abou tthat
JF: Most browsers can keep
multiple profiles, offering dynamically different values that
might be added
... but the WCAG requirement scopes it to the user
AWK: autocomplete is not the primary purpose of this Technique, but identification for future AT - to that raised the concern that it may not be as helpful as we hope
JF: Only scoped to particular user - so the identification would still work apart from the autocomplete function
AWK: That poit was raised if it is possible to automatically identify that something is about the user, without looking at the context
JF: the same applies to othe
rissues like alternative text
... making the explicit declaration fo rthe user helps the
AT
... YOu may have five different email fields on a page so the
one that has the additional metadata is the one exclusively
scoped to the user
AC: The question is if it is considered a failute to use autocomplete on OTHER fields (not about the user) would that potentially clash with the intention of the HTML spec?
JF: all autocomplete values so
far are scoped to the user
... you don't want the browser guessing if fields are not about
the user
Jon: The point about having multiple profiles is having autocomplete, so there is a concern about not using autocomplete on those fields - we need to make sure we are not at odds with other people using the spec
AC: There is nothing in the spec on multiple profiles
Katie: Finds it useful if information on others is stored in a profile so that should not be prevented
AC: Browsers use their own heuristics
JF: The bug may sit
inWHATWG
... Spec talks about providing a hint
... multiple profiles is probably the exception not the
rule
AC: Aspect of multiple profiles is worth keeping an ey on
Jeanne: has three people providing info architecture prototype input
Updating style Guide
scribe: David tackled a version of 1.3.1
<alastairc> David's draft: https://lists.w3.org/Archives/Public/public-silver/2018Nov/0054.html
Jeanne: Please try your hand, and give us feedback
<david-macdonald> http://davidmacd.com/WCAG/silver/information-relationships.html
Brooks: Did you get the material forwarded?
Jeanne: will check
... found it
AC: Want to talk about your draft?
David: Wondered where the
testability / measurability lives? Where is conformance
determined?
... wondered why technology was removed from the SCs
<scribe> ...new mandate is frequent update of the standard
UNKNOWN_SPEAKER: creates
opprotunity to simplify / collapse the structure - makes
methods the structure to measure conformance
... starts to make things a lot easier - not so many
layers
... hard to rewrite stuff - but when taking out testability, it
can be made simpler
AWK: Started working on the
keyboard SC - similar questions... can rewrite short
description, but once thinking about methods, there are so many
- if these are the only testable items. it changes a lot,
requires more comprehensibility
... one of the values of Techniques is that people can come up
with their own - nit knowing how testability would work was a
hindrance of completing the rewrite
Jeanne: good point - we need to consider what that means on a methods level
JF: WCAG 2.1 strayed away form
tech independance - we recognise that we need more tech
specificity
... unclear what the tagging and profile would look like -
different profile fopr mobile and desktop, in the latter
orientation may not apply - so we may need smaller testable
statements...
SCRIBE?
<Rachael> I can take it.
<Rachael> scribe: Rachael
Jeanne: Planning on smaller testable statements. Still working on tagging prototype. In examples, the tagging will become more robust.
JF: Question about testability, because all testable statements are tagged, we would expect the information would change based on platform.
Is that correct?
Jeanne: That is what we are discussing.
<AWK> Some monitors do rotate, fyi
The value of this exercise is to bring these issues up
<alastairc> ak br
Brooks: Thanks for the opportunity to give input.
Introduce the concept of sharing the load across all the parties responsible for user experience. Users, Content creators, etc. Share the responsibility so its not all on content owners. That makes it easier for each party to comply.
I'd like us to move the standards to a place where we can share that load.
Jeanne: Thank you for the interesting methods you came up with.
Ryladog: Monitors do rotate. That isn't a constraint.
Alastair: In terms of conformance, where are the testable statements. How does that affect tagging and profile. Thinking about granularity. Some of current guidelines include many things (info and relationships) and some are quite specific. Its hard to rewrite one and then understand the entire process. I need a bigger picture to put this together.
<jeanne> I am familiar with the rotating monitors. I used to own one. The principle of what JF was discussing is discussing is the interesting part, rather than the specific example.
AWK: 1.3.1 - I would be reluctant to break it apart to make it technology specific. I think it can be broken apart and maintain technology independence.
Objects that are tables need specific information. That isn't specific to HTML, PDF, etc. We can maintain tech independence and then dig in at a tech specific level. This is what we need to figure out.
Jeanne: Was it not clear in the examples that testing is in the methods? We'd like to update if not clear.
AWK: Not clear
... Techniques now need to be testable but the success criteria
needs to be testable as well. I wasn't clear if the description
needed to be testable.
Jeanne: The description in the guideline was not intended to be testable. The description in the method is intended to be testable. We need more work on the template. Good feedback.
Detlev: Combination of methods. Do you have to test positively across several methods to comply? Example: you meet bypass blocks using skip links, headings, etc. Even if you give up testing on SC level, you will need a mechanism to meet the minimum requirements.
AWK: Something like language of page is easy because its a constrained set of techniques. But if you get to keyboards, there will be many different methods and we will need to define what subset is ok.
Jeanne: I'd rather not go there yet. Its on the conformance side but we dont' have a prototype for conformance yet. We really want you to try the architecture and plain language. Please hold those thoughts for a few weeks.
Alastair: For most of us, it is a hard exercise without knowing how the pieces fit together.
Any questions from anyone else working on this
?
It would be useful if people have a bit more time on this as well.
Jeanne: This is valuable and we learn from each person who has taken the time to do this. We recognize how hard it is to do this without knowing how it all fits together which is why we want you to sketch it out and note issues.
Wish we'd included a comments section at the bottom of the templates. Please pretend its there and note all the issues you see to ensure we see them too.
Alastair: Are you collecting these so we can look at other examples?
Jeanne: Will give everyone a link to the page.
<jeanne> https://drive.google.com/drive/folders/13ZUtgIDUyC8KTQcQqLzjqluDX7Z9fhmx
Alastair: Would you start a thread on the general list with a link and request for comments?
For those who haven't tried this, please try and comment.
<alastairc> https://github.com/w3c/wcag/issues/523
There is a proposal to remove the link. The question was whether anyone had a better link or should we just remove it?
<alastairc> Providing an alternative for time-based media for audio-only content
Alastair: We had four people comment. All agreed to remove the link. Does anyone object to removing the link form G158?
RESOLUTION: Remove link from G158
<alastairc> https://github.com/w3c/wcag/issues/517
<alastairc> Update: https://github.com/w3c/wcag/pull/530/files
<alastairc> In cases where the state of a user interface component is apparent without relying on visual information, this Success Criterion does not require that visual information meet the 3:1 contrast ratio. For example, the Active state on a link does not rely on the visual information because the user is actively clicking on the component at the same time.
Alastair: Update to the understanding document to add a paragraph.
Responses thought it was ready for publication. Bruce thought it might be better as normative.
Bruce: Its come up before about the contrast but I think its a good note to add.
Alastair: Does anyone object to that or have comments?
RESOLUTION: Accept pull request 530.
<alastairc> Next week: https://github.com/w3c/wcag/pulls?q=is%3Apr+is%3Aopen+label%3A%22Ready+for+WG+Review%22
Alastair: We haven't had a lot of +1 in github so I'm preparing items to queue up to review each week. I try to work through them. If you get a chance before the next agenda goes out, this is what will be on it. Though they dont' have enough +1s, this is a mechanism for getting it in front of the group.
<alastairc> Tracking spreadsheet: https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=0
Look at the spreadsheet for tracking these
Some of these are published but a few that are not published have names next to them. If need the link for what you signed up for, there it is. If we complete the spreadsheet, we will have a new technique for each SC.
<alastairc> Example preview: https://rawgit.com/w3c/wcag/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html
RawGit is still going if you had a repository before it ended. For those who are authoring techniques, I'll send around instructions.
Bruce: Who pulled the plug on RawGit?
Alastair: The guy who set it up. People were using RawGit to distribute malware.
Hopefully we will get an alternative but while that is in progress, we can continue to use RawGit.
Alastair: Any other business?
Bruce: I don't think the minutes from last week were posted.
<alastairc> https://www.w3.org/2018/11/13-ag-minutes.html
AWK: They are published.
Alastair: I will check my email as well but the link is above.
Anyone else? Please use the extra half hour for a technique or silver prototype.
Issues with accounts are being resolved.
<alastairc> 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) Succeeded: s/ac j// Succeeded: s/ WHAG(?)/WHATWG/ Succeeded: s/that testing isn't in the methods/that testing is in the methods/ Default Present: AWK, alastairc, Detlev, JakeAbma, Makoto, Rachael, stevelee_, bruce_bailey, Chuck, MichaelC, Brooks, MarcJohlic, Katie_Haritos-Shea, JF, JeanneSpellman WARNING: Replacing previous Present list. (Old list: (no, one), alastairc, Detlev, JakeAbma, Makoto, Rachael, stevelee_, bruce_bailey, Chuck, MichaelC, Brooks) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, alastairc, Detlev, JakeAbma, Makoto, Rachael, stevelee_, bruce_bailey, Chuck, MichaelC, Brooks Present: AWK alastairc Detlev JakeAbma Makoto Rachael stevelee_ bruce_bailey Chuck MichaelC Brooks MarcJohlic Katie_Haritos-Shea JF JeanneSpellman Found Scribe: Detlev Inferring ScribeNick: Detlev Found Scribe: Rachael Inferring ScribeNick: Rachael Scribes: Detlev, Rachael ScribeNicks: Detlev, Rachael WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 20 Nov 2018 People with action items: 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]