Scribe: Chuck, Chair: AlastairC
ac: Announcements
ac: Survey... First two are straight forward. Second two were new or refined techniques. If we cou....
ac: Everyone seemed happy with the change. Mike suggested. Just removing the old techniques that we had from WCAG 2 got added to status messages. Didn't seem right. Everyone agreed.
ac: any comments or questions?
<silence>
ac: If no objections, we will resolve to accept.
RESOLUTION: Accept pull request 568
ac: wording update for reflow. bad drafting to start with. Not so much a typo but about going to 200%. Someone put in a pull request that changed all references in one paragraph. Hard to spot in a diff
ac: It is NOT required to achieve 200% at every breakpoint rather than 200% or larger at every breakpoint.
ac: Objections?
<silence>
RESOLUTION: Accept pull request 575
alastairc: Link to preview: https://cdn.staticaly.com/gh/w3c/wcag/tech-failure-unmodifiable-single-key-shortcut/techniques/failures/unmodifiable-single-key-shortcut.html
ac: This is a failure technique for character key shortcuts.
ac: This is from detlev (who can't make it today). both techniques may be from detlev.
ac: One person thought it was ready, a few had comments on things to change.
ac: Mine were just moving some things around, adjusting procedure step. Didn't see Andrew's before I made mine. Andrew had a few comments. There's some overlap between us.
AWK: You want to just work your way through my comments?
ac: Yes, just trying to decide given that detlev is not here, they look straightforward.
ac: Other people were agreeing with those... Yes we can step through those.
ac: First one brackets ... working for a realistic example. If you have a different example for that Andrew?
awk: We should'nt publish with that parenthetical.
ac: I also didn't understand why we would start the procedure with reloading page and checking with focus set. It looked like you could remove that bit if you click on an empty part of the page.
Katie: Isn't there a reason he put it in there?
ac: does anybody know what it is?
Katie: To make sure nothing else is running, not a bad thing, we should ask him.
ac: Strange thing to put in a technique. No other technique has that. What's different about loading a page vs reloading a page. The only thing I can think of...
awk: you are already in there.
ac: It's explained in the first sentence of the notes. If the site sets the focus to a search box or select drop down, that would act like a keyboard shortcut. The key bit seemed to be click on a blank area of a page.
ac: That's the bit that makes the procedure work. First half of step one doesn't seem to be needed.
ac: <reading comments>
awk: Most of the things we are asking, most of these are checks. The way it was written in here feels different than we usually do. there's nothing... it's not asking anything. We can't really say yes or no to this.
awk: For this sc there are two possibilities. either the shortcut's don't trigger functions OR if they do then there's a way to disable it. In this case it bundles it all into this fourth step which makes it confusing.
awk: The way it's written, the 4th step doesn't really capture the whole picture. "If keyboard character keys trigger functions then check this". I don't think it clarifies anything the way that it could.
ac: It doesn't look like you suggested a change to that last step though.
ac: You did, next one.
ac: Basically you are saying if pressing keys triggers something the check to see.... <fast reading>. Do we need the shift version?
awk: that was my other question. Whether that was... Does the sc... would I fail if I had shift-s as my keyboard shortcut?
ac: I thought that would be a modifier key.
awk: It's certainly not a character key. And also in the sc it says "if a keyboard shortcut is implement in content using only letter, character...." the following is true... it doesn't say anything about shift.
john: Shift is the modifier key. Could be ctrl, alt, apple key. Focus on this was on single key shortcuts like gmail. I remember kim recounting... ...if somebody says something or says a letter, and she's using speech input...
jf: That was the scenario that single key keyboard shortcut could be triggered accidently.
ac: SC text says including upper and lowercase characters. If you are using voice input that's case insensitive.
ac: Maybe we could term it "including capital letters".
jf: I'd be less specific about the shift key and go back to modifier key.
ac: Test procedure is saying to include s and shift-s as part of the... if shift-s triggers, that's a failure. If you have ctrl-s, that wouldn't be a failure.
<alastairc> SC: "If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true"
jf: This is where I'm confused. If you include modifier plus key then it's no longer a single key shortcut.
awk: Gower pointed out that this isn't about single key, but more character key. If you use shift....
jf: It's no longer a single key shortcut.
ac: This is a failure technique. Do we think "shift" plus key is a failure.
awk: I don't think it's a failure...
mike: How do you get to uppercase without the shift?
awk: Does that make the shift key a printable character?
mike: I'm just pointing out the issue. I will note that... I'm not sure if we even need this failure technique. IMO can you not just do a search or... scripting for key capturing... for an automatic rather than manual test?
ac: In detlev's notes he mentions that viewing page scripts and looking for triggers or... without modifier keys like alt or... there are several ways of implementing character key events. Detlev doesn't think so.
ac: Doesn't think that's a reliable way of testing it. Just a shame I didn't get his regrets until....
mike: Realistically, people won't carry out this test on their page. This and a couple of other techniques, we have to make an assumption that this will be caught in automatic testing. In the situation...
mike: I don't think we need a failure technique to show...
ac: It's one of those that we had in our list of things to do. Detlev took it on. Not the end of the world. A couple of open questions. Do we need shift, how does that work?
ac: Whether or not an automated way could be reliable or pull up potential failures. I think we will leave this open for the moment. Couple of key questions for Detlev. Will pick up in future.
awk: Ask him what the str key is.
ac: Agreed.
awk: German version of ctrl? Typo?
RESOLUTION: Leave open
AWK: I brought up a pic of a german keyboard. strg as ctrl key.
<alastairc> Preview: https://rawgit.com/w3c/wcag/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html
ac: This technique is a refinement on... we looked at it before. We had questions... A japanese equivalent was provided for one of the examples. I can't read it out, similar to send mail one.
ac: Four people had comments. Andrew got in first.
ac: <reading recommendation>
awk: That was mostly a readibility suggestion.
ac: OK. 3rd desc paragraph seems redundant to the first. So readability, just dropping a section of that.
awk: Yes. Parentheticals distract you from train of thought. Since we already did the ... to identify what's the label in the first paragraph, doesn't seem like we need to do it again.
ac: last example.
awk: That's not what I would want it to say. When I look at the example there with ... tried with voice over, I don't know why we would suggest the accessible name includes 3 because 3 is the value.
awk: Those three things together are order and then things and then thing num which is labeled by thing label, which is thing again. I'm not sure that this is right.
ac: I wonder if we can just drop this example. Seems more complicated than it needs to be.
ac: <read comment> I think that was something I asked to be added. Most common example we find.
ac: If alt text (usually) doesn't include that, then presumably an issue. I'm happy to call it linked images containing text.
ac: One comment I had ... all of Andrews comments can go straight in unless any suggestions or variations.
ac: Only comment from me, don't know if japanese example actually works or not. We are reliant on Mikoto or someone who has Dragon and speaks Japanese.
ac: I'll email Mikoto separately on that.
ac: Jake had lots of comments which are fairly direct. But didn't say where each thing is that he is commenting on. Same comment as andrew on parenthesis.
jake: Refresh browser.
jake: Top six is more textual. Readability part. Other ones not specifically.
ac: OK. Just going through....
ac: Top ones look like small text things that can just be done.
ac: Last one of those text things about text and image links. I'd rather go with Andrew's version.
ac: Other suggestion would make sentence much longer.
ac: For the other ones...
awk: Where is that?
ac: I can't find that text you have in there jake.
awk: Just above the...
ac: <reading> Changing that to resembles. I know they are not exact, but I think just in english corresponds is a better word. Resembles allow for a lot of change.
awk: How about "is included in".
jake: Gave me the feeling it needed to be exactly the same, but resembles allowed for...
awk: Good comment.
awk: change to "is included in". We are saying visible label has to be included in accessible name.
Jake: that's perfect.
<crosstalk>
Jake: That's not what this is about. that's not part of the accessible name.
ac: OK. Good point.
ac: <reading> Is this a comment on a particular part of the understanding document?
Jake: Yes... <reading fast> when we talk about the button next to an input field. John always tells us it's a label for the input, though it's a button label.
Jake: ...but it's not programatically linked. That makes it an interesting one.
ac: Would that be better as input with label.
<AWK> add "text intended to clarify the purpose of a control"
jake: I'm not sure if Dragon does heuristic analysis. Such as focus search input because of button next to it is accessible label.
awk: I think we should change this, it's true that programmatically linked labels do count but if people used those all the time we wouldn't have this sc.
awk: We can either replace, ... or we could add another item text intended to clarify purpose of control.
<alastairc> replace "programmatically linked label, value of input" with "inputs with visible labels"?
Mike: I'm hoping I have language in the understanding doc which helps clarify that.
ac: We want to cover anything.
Jake: Just an example, don't make it complicated.
awk: Do we think in the procedure we get rid of that parenthetical? We could remove it if we clarified that maybe in one of the examples that does this situation.
awk: We could make procedure clean.
Jake: Yes. If it's not there, it's also not wrong.
ac: Yes. I don't know if it's worth expanding on that...
jake: It's even so that we mentioned it in the first paragraph, and then in the second or third. This is the third time we mention it. It's already covered on the top.
Jake: This is the third time we mention what it's about.
awk: Yep.
<AWK> I'm editing the pull request with our changes
gowerm: I've been obsessing about this one a little bit. Big problem when people use aria-label. I'm going to right a failure technique, it's going to include aria-label when other labels are visible.
gowerm: ... I mention that. You see that aria-label coming up as a culprit.
gowerm: Going over it with a fine tooth comb, see whether or not outliers go in this technique. Group name considerations, single labels with multiple inputs. I'd like to have something that's clean.
gowerm: Where this sc is needed is where people override it or the label is not obvious (outlier cases) This is a good starting point.
ac: Looking forward to your understanding document.
gowerm: Two things we are... these are going to have to be automated tests. No way testers can understand the issues. Amount of effort required to inspect every ui component for accessible name and scan for visible label
gowerm: not feasible.
ac: One we find most commonly is text in images.
jf: Just want to go back. You said aria-label is the culprit. You saying we don't use aria-label?
gowerm: No. Non-extraordinary u/i, it's use of aria-label will lead to failures. You can almost make a rule to check for aria-label in the u/i, and ask if this is replacing visible label.
gowerm: We are addressing programmatically determinable text. Going to have to be good enough for automated testing. Not realistic to test every single object.
jf: Depending on testing tool. At some point, we already have similar functions. We have people reviewing alt-text. I appreciate that level of testing is a q/a level function. I'll push back on "unrealistic".
gowerm: Whole lot more u/i than images.
jf: tool can identify the instances in dom and do the highlighting function and telling human to verify.
gowerm: FYI that's how we are implementing it now. If there's a mismatch there's a violation...
ac: Interesting tangent. Coming back to THIS technique. Jake says ...
ac: <reading comment>
ac: Jake you are saying does this assumption built into the procedure undermine the success criteria?
Jake: it only says the accessible name contains the same letters in the same order. But I didn't have time, but I thought we were very specific it needed to be a prompt or at the end. That should be in there.
Jake: The other one is if the letters are in the same order as the visible label, this was the first one that popped up in my mind "depart" or "departing". Should be more focused on what we want here.
<AWK> https://www.w3.org/TR/WCAG21/#label-in-name
ac: I think we've gone through a couple of iterations. We want to encourage that they match. If they don't match then we want the visible bit to be the accessible name. Still a question if it works in other languages.
ac: because of that we need flexibility. that's why we came to "same letters in same order".
ac: I thought that's where we got to because we needed flexibility or some things wouldn't work.
Jake: didn't have time enough about an even better example. But if accessible name has same letters you can still have a mismatch. We will probably come up with a lot of mismatches.
ac: Andrew put in link... "name contains the text".
awk: In a technique we can. You can have a technique that says accessible name matches label exactly. If there's anything additional, you can't pass, but you COULD use another technique.
awk: Jake's right in that this makes it more broad. Question is...
awk: any realistic cases where this will come up. I get what Jake is saying. If label is apt and accessible name is "apartment" this shouldn't pass.
ac: I remember having this conversation and saying that's fine we need two techniques, one narrow case. Technique produced at the time is a broader one. Short answer is.
ac: This technique is more closely matching sc, but we could do a more narrow scope.
awk: Another check? Accessible name, meaning of accessible name is consistent with meaning of visible label. So that in those cases where there is letters that combine into other words.
awk: Would that help?
Jake: I like it!
mike: You had something on mismatches.
awk: Once this one is done we can make that technique easily, which not everyone would use.
mike: We can state the obvious. If folks are implementing visible labels with typical constructs, this is a free SC.
mike: There are creative ways that this could be blown. I know that there's a technique that says astrick must be in label. Someone had astrick followed for tag. That kind of thing can happen.
<AWK> can add <li>The meaning of the accessible name is consistent with the meaning of the visible label.</li>
or "matches the meaning"
mike: Do we need to handhold or rely on common sense? For mismatch... that will happen when someone overrides visible label. There's only two ways to override visible label.
mike: And I don't know how much we need to go into parts of labels if we make it clear that the way to meet this is to match them, and talk about what are U/I failures.
mike: That's kind of where I see aria-label comes in. That's the stuff we need to provide guidance on. It's design decisions.
ac: Having an aria label on an image is a different issue. I don't see it's in scope for this one. I see your point overriding not great label text.
<jon_avila> If the dot dot dot was left then they could also add more text in the accessible name of they wanted and still conform
mike: One last point. I've found "Title" is an amazingly useful thing within the confines of this SC. Title is , if there's nothing else, title will be used as accessible name. Where there is something else...
mike: Title becomes the description.
jf: Is that what it says in the spec?
<Ryladog> I agree with Mike on Title
mike: Imagine a telephone number. What's best way to construct that? To meet this SC telephone number is going to have to be accessible label of the first name. How do you convey that this is one of three fields?
jf: Wouldn't that be on the grouping?
<AWK> Mike you ready to scribe?
mike: No, not part of the input. Name of group but not name of input?
scribe:gowerm
Rachael: More of a question. How are we handling abbreviations with this SC?
<alastairc> Equivalent to: <button>Send <span class="accessibly-hidden"> Mail</span></button>
Rachael: If we have a button that says "Ctrl" and we make the name "Control" would it fail?
Alastair: Yes.
AWK: Did we mention the technique about matching? [Laughter]
Alastair: I feel like this technique is trying to outline the minimums. I'm not sure how adding a meaning check helps with this technique
AWK: I think the point here is that you can pass this procedure and have something that can be wrong.
AWK: "part" and "departed". I don't know when that would come up in reality.
AWK: I can go either way. I'm not convinced this is going to come up as a problem.
AWK: Jake are you okay coming back to this if it emerges?
Jake: Sure, people can come up with wierd realities.
AWK: For me, the cost of adding this is people getting confused.
AWK: Especially for something that may never come up
Alastair: It's not explained above either.
Alastair: I think we'll make this one on hold, pending a test from Makoto
AWK: I'd like to incorporate as many of Jake's cahnges as possible, but I'm not sure we reached consensus
Alastair: I don't want to do this live... I preferred the last one
AWK: The penultimate one was redundant to mine
Jake: The 4th one "defines..." I think is how the accessible name must be constructed
gowerm: should we add the HTML accName?
AWK: We should include both the HTML and ARIA accname info in the resources.
<jon_avila> I hope we can have a matrix to cover all the known possibilities abbreviation, capitalization, group name, symbols, ellpisis, and 1 vs. one.
https://w3c.github.io/html-aam/#accessible-name-and-description-computation
Alastair: Any objections to publishing as amended?
RESOLUTION: Publish as amended.
Alastair: We have our survey around potential 2.2 SCs
Alastair: We have quite a few potentials that have come from MATF and LVTF from gap analysis.
Alastair: Compared to 2.1 we have a relatively smaller set we could work through in a backlog kind of way.
Alastair: There are quite a few where people have scored a few 7 and others 0.
Alastair: Some people have rated them 'if we do 2.2, here are the priorities' which is not what I was looking for.
Alastair: Are people seeing enough things that could be worked on pre-Silver?
Alastair: It's hard to read comments because they get so thin.
Alastair: I added 4 COGA criteria, TBC
Alastair: COGA is meeting today and will be coming out with a list
Alastair: opening floor for comments
Katie: I think these need to be included in Silver. I think they're important and good things for silver
Alastair: Would the timeline for silver affect your opinion?
Alastair: If it was going to take longer than 2012, would that change your opinion?
Katie: No, we need to be focusing on doing silver.
Rachael: I agree these are important. I think it would affect whether silver is going to be 2, 4 or 6 years out.
Rachael: If we are involved in silver, will that hasten it? That's what I want answered.
Alastair: I wish I knew off hand.
JF: As someone who has been calling in to Silver, I think at this point in time they will not make their deadline
JF: The larger point is I don't see this as a binary either/or. We can keep working on both simultaneously.
JF: If folks think more effort needs to be on silver, yeah. Only about half a dozen are regular in attendance
JF: Mike Gower, I feel like you and I left TPAC working on a 2.2
JF: I would be concerned if we stopped that as we figure out how silver is going to come together.
JF: I think a lot of ground needs to be covered.
Alastair: I'm unsure whether this entire group showing up would speed things up that much.
Alastair: I wonder if us working on items near-term would also benefit silver. it's the ones that can't fit in the 2.x context that I wouldn't want to focus on.
JF: You're right, Alastair. Adding more chefs doesn't necessarily speed up the meal. I don't think it's realistic to think it's going to be ready.
AWK: The current timeline has been reaching REC three years from now.
AWK: It definitely won't be in the next year or two.
Katie: I think we need to focus on silver. If we do 2.2 we will be splitting ourselves up.
JF: I agree, the work is being done now. But I see silver as another task force. If we want to elevate it, fine. But I don't see it as binary.
Katie: If we move the main working group to that, then it is no longer a TF and that becomes our focus.
JF: That calls into question the maturity of the framework.
JF: When you try to put it into practice...
JF: I think there's still going to be a lot of parallel work this group needs to be thinking about.
JF: Based on what I'm seeing on the weeklies, I don't see making a 3-year runway.
Katie: I think my questions are fair. I think we just disagree.
Alastair: We agreed at TPAC to do some more integration, but I don't think all of us showing up there would solve this.
Alastair: Do other people think there are useful things to work on?
<JF> yes
<bruce_bailey> +1 to what mg is saying about 2.1 still needing support
gowerm: I think multiple iterations is worthy, but we're still resolving 2.1 things, needing techniques, updating understanding docs. BUT, don't want to miss updates.
AWK: When we seek a charter, each org will need to have a position on it
Katie: Silver could become our work, with the Task Force looking at 2.1.
JF: I'm concerned if we made Silver our primary deliverable and we had a three year charter that starts 2020, we would have to deliver silver at the end of three years. I don't think we're ready.
<jon_avila> will they even give us a 3 year charter?
I see the AC giving us a shorter charter like 18 months
Alastair: I do wonder, given the plans are being drawn up but the house isn't there yet, I wonder if a few people from the group would be able to help with that.
Alastair: I just don't think it's ready for us all to jump in.
JF: Maybe we should have direct discussion with Silver about this. Outside of Jeanne, most showing up are not that aware of w3c process.
JF: Some expertise might be welcome.
Alastair: That might be a good agenda piece for CSUN
alastairc please check out: https://github.com/w3c/wcag/pulls?q=is%3Apr+is%3Aopen+label%3A%22Ready+for+initial+review%22
There is also this: https://github.com/w3c/wcag/issues/582
Role of img: https://github.com/w3c/wcag/pull/531
Alastair: Anything marked Ready for Initial Review is worthy of scrutiny
Alastair: Please do a pull request.