<AWK> https://www.w3.org/WAI/GL/wiki/Scribe_List#2019_Scribe_History
<jon_avila> scribe: jon_avila
<AWK> Scribe: Jon_Avila
awk: Christmas eve is the 24th
which is a Tuesday and so is New Years Eve. Plan to not have
calls those day unless anyone needs it.
... In past we generally don't have a call after TPAC. The next
date after that would be the 24th of September. What do you
want -- should we have a call that day or have a more casual
call to check in post TPAC.
RESOLUTION: no calls September 24th, December 24th, and December 31st.
awk: survey on updating an SC in WCAG 2.2 -- but does relate to how we update existing SC. This discussion is around a suggestion to a change around reflow. The big question is do we update the SC text and understanding or add a new SC.
<Detlev> pleaee refresh survey
awk: A new SC would come in at
1.4.14. Benefit to update SC -- keeps the number of SC smaller
and more clear -- but complicates when people are trying to
evaluate for both WCAG 2.1 and 2.2.
... Option 1 to update - 5 votes. Option 2 - 0 votes. Option
something else has 1.
<laura> https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2019Jul/0022.html
Laura: Wayne sent email to LV
taskforce on topic. Laura agree's with Wayne. We should
language fixed for 2.2
... Changes need to make sure they map back to user
requirements and we want to give users of the docs time to
learn the docs before changing them. It would spread confusion
and could impede adoption.
Alastair: Was trying to use this
as a case study -- the example is around reflow. In this case
-- would we be able to update an SC as we have outlined in the
requirements document?
... Doc indicates that we can -- but today we have not used
that route. That is the question with this SC as an example.
Due take the points on whether this is too soon about low
vision requirements -- just slightly different than what he was
trying to get at.
Chuck: Not an advocate one way or other. Meaningful and straightforward change. If we can't do it in this situation -- can't see how we would do it any situation.
Rachael: As we add more SC that qualify other SC we are encouraging people to create secondary tools. For new developers its going to be difficult for people to sort out and people might create their own checklists and we should be aware of that.
<bruce_bailey> for better or worse, we *did* pick a particular resolution rather than requiring "down to"
Detlev: In this case - advocate updating as this just makes it more clear as this just clarifies the common understanding as how people apply this. It would be confusing to create a new SC and that outweight any issue with updating SC.
<bruce_bailey> i think Alastair was trying for a non-controversal example!
Alsastair: This question is to determine how we do it rather than if we do it. It's a good example -- but that is a separate issue.
<Zakim> bruce_bailey, you wanted to say sorry for missing this survey. In general I am for updating SC, but not this time.
awk: was some discussion about this specific example and the testing demands.
<Zakim> mbgower, you wanted to say I feel like we agreed that how we update 'depends' on the context. For reflow specifically, I've heard pushback from LV.
Bruce: Agree in general with updating SC in place. This is a bad example of that.
MikeG: Bit of a rehash of last week -- the short answer is it depends. Reflow doesn't seem like a good example to use, as it is contentious
awk: Updating is acceptable is what most people say. Laura is raising the decision or not to change because they are new -- the jury is still out. So if you were agreeing that one was necessary such as minor wording change -- updating might be an appropriate way of handling it -- would you agree?
Laura: Would be ok for bug fixes.
<alastairc> Not just bug fixes, for increased requirements.
<bruce_bailey> we can have bugs that are normative
awk: we already have the ability to have an errata. The language is effectively changed in 2.1 as well as future published versions. But we are talking about some slight modification.
Laura: It would be a cleaner option than a separate one
<bruce_bailey> +1
<alastairc> +1
<mbgower> +1
<Detlev> +1
RESOLUTION: WG agrees that updating SC is a possible option. But no decision was made on updated on SC 1.4.10 at this time.
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/Techniques-issues-July-2019/results#xq8
awk: right now this is unanimous but MikeG indicates we might be looking at wrong thing.
<AWK> Technique: https://raw.githack.com/w3c/wcag/keyboardShortcutSufficientTechnique/techniques/general/shortcut-mechanism.html
MikeG: Linking to the right technique -- but wanted to flag confusion over the wording of a failure or sufficient technique
awk: suggest flagging issue in
github if there is a gap separate from this.
... not a huge number of people who have reviewed and approved.
Now 4. Any objection to accepting the sufficient technique as
proposed?
RESOLUTION: Accepted as proposed.
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/Techniques-issues-July-2019/results#xq9
<bruce_bailey> https://github.com/w3c/wcag/issues/722#issuecomment-490876875
awk: Current proposal summarized: Logos are not exempted but sometimes may or may not include additional text that may or may not need to be included.....
MikeG: Proposed response is ok -
might be some nuanced missed. 3 things. Exclusion for logos in
images of text. For label in name we have similar issue where
image contains text.
... explicit example in images of text and it states that it
has to have alt text. Alt text will provide part of the
accessible name calculation. So it seems to be in scope.
<alastairc> I'd note that, in Dragon at least, if there is a link for "Home", saying "Click home" will take you to the *browser* home page, it doesn't follow the link. The company name would be important for a logo-link.
MikeG: 1.1.1 requires linked
images describes it's purpose. For label in name - most logical
is to append function like home to the text of the logo. The
best alt text is "IBM Home" to meet label in name.
... Writing out International Business Machines would pass but
would not be best optimal.
Bruce: Label in name is for people using voice recognition. How could people hope to guess what the logo acc name could be written.
<mbgower> I definitely wouldn't want to exclude logos.
awk: some interpretation of logos
might apply. in this SC we didn't explicitly exempt logos
... Several commenters such as SteveR indicates text and
purpose should be included in the accessible name.
detlev: Some other logos are harder to read or not easy to decipher. Complex situation and warrant some explanation in understanding text. Maybe user would not know logo wording but could say "home" or "start page" to activate.
awk: looking back at the proposed response it seems to allow for text that may or may not included. It has the same level of subjectivity as writing alt text.
<Detlev> agree
awk: what do people want see changed or added to this proposed response to Detlev?
<alastairc> Perhaps we should add an example to the understanding doc?
detlev: see cases were there is a logo but people give "home" or "start page" without the logo name. Maybe good option in some situations were logo is not clear. If people don't include company it might be a good option in some situations. It requires subjective assessment. Judgment call may be needed. Would like an answer that doesn't mandate precise manner.
MikeG: "home page" as accessible name alone is bad option in my opinion if it doesn't reflect text in image of logo.
awk: In some cases you could say logo like IBM is decorative or artistic representation.
Alastair, tested with Dragon -- click home will take user to browser home page and not links with home in it.
awk: Seems like a common understanding. Do we need quick edits?
MikeG: will make an edit in next few minutes.
RESOLUTION: Leave open
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/Techniques-issues-July-2019/results#xq10
awk: Comment is that techniques
are a problem for browser support today. Should just focus on
HTML lang attribute. Can you see pull request with changes.
Some edits as well to the content to remove where it talks
about xhtml. changes reflect current best practice.
... 5 people want to approve. Mike G. recommends some changes
including putting HTML in uppercase in title. Alastair has
already done that.
Alastair: browser support issue with xml:lang? Commenter said xml:lang was forbidden in HTML5 and only works in Chrome. Don't know if it's harmful in terms of our technique documents that use both internally.
awk: Now have 6 approved with the change of HTML. Any objections to accept as amended?
RESOLUTION: Accepted as amended.
awk: F63 had included a reference
to something that group has decided couldn't be relied upon
previously.
... removed preceeding heading in two places - list of ways to
meet and in check. Mike G. Also recommends removing h80 as
advisory technique. That's more a debate to get it down to an
advisory technique as it was previously sufficient.
... Everyone seems to approve. Any additional thoughts to make
F63 consistent with earlier decision.
RESOLUTION: Accepted as proposed.
awk: 4 people approved. Some small editoral items.
Alastair, also takes out applying text contrast within graphics which we had agreed to graphics.
awk: should just be github issue with two pull requests and that will be cleared up.
<AWK> Jon: related to alastair's comment, I see a loophole if the text in the image doesn't meet contrast and is also the way to meet graphical contrast requirements.
RESOLUTION: accepted as proposed.
<MarcJohlic> scribe: marcjohlic
<jon_avila> thanks
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/Techniques-issues-July-2019/results#xq13
<alastairc> Authors may choose to exceed the recommended point sizes / relative size differences from the base font size in order to compensate for this.
<Detlev> added a comment to survey...
Alastair: Minor but a normative change
AWK: I don't know if we should do
this. Not because I disagree with the sentence, but I don't
know that this sentence adds a whole lot.
... Note seems obvious as is so do we want to start adding
errata for things like this?
<jon_avila> I agree with AWK that this is an important issue but the understanding doc seems like the better place.
<laura> +1
AWK: What do other folks think?
<laura> both
<bruce_bailey> agree that this should be in Understanding, not Note
AWK: Do we already have anything in the Understanding doc to cover that?
Jon: Same note is in the Understanding doc about Thin or Unusual fonts
<bruce_bailey> sorry, how do i GitHub pull request to show me change being suggested?
@Bruce - try this view and see if it helps: https://github.com/w3c/wcag/pull/774/files
<bruce_bailey> here it is: https://github.com/w3c/wcag/compare/Large-text-note-228
AWK: Should we table this and we can modify the PR to make a change in the Understanding doc instead?
Alastair: I can do that if folks agree
Jon: Person submitted is saying that we need to provide more details on how to address or solve how it's measured
<alastairc> Suggest updating this sentence: "Since there are so many different fonts, the general measures are used and a note regarding fancy or thin fonts is included. "
AWK: We have a tool now that talks about what is "Large scale" but realizing that's generalized due to differences in fonts. Folks could use fonts that still worn't work well and that's the point of the note - make sure you don't do that.
Alastair: If folks are happy w/ that change I can put it in
<alastairc> To: "If you choose a particularly thin font, it is recommended to exceed the recommended point sizes in order to compensate for this."
<Detlev> Much easier
+1 to alastair's suggested Understanding doc change
<laura> +1
AWK: Do folks like the change?
<alastairc> Just above the first note on this page: https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html
RESOLUTION: Reject PR so that this is not an errata, but rather put the change in the Understanding document
<AWK> https://github.com/w3c/wcag/issues/722#issuecomment-490876875
<Detlev> Revised rsponse looks good to me
<alastairc> +1
RESOLUTION: Accept as amended
https://www.w3.org/2002/09/wbs/35422/Techniques-issues-July-2019/results#xq14
<alastairc> https://github.com/w3c/wcag/pull/767
Possible mixup in the PR link - survey was actually linking to #832
Alastair: Right issue (767) wrong PR link
AWK: Maybe leave this one until next week so we can give folks another chance to look at
RESOLUTION: Leave open
https://www.w3.org/2002/09/wbs/35422/Techniques-issues-July-2019/results#xq15
AWK: Mike says it needs more discussion: "I can live with it, I guess. I've never liked the paragraph element being the association for a link's purpose, but it is in the guidance. Rather than skate around it with a construct like this, I'd suggest considering the removal of <p> as an allowed assocation in 2.2. There is not really an excuse for ambiguous links IMO."
<AWK> https://github.com/w3c/wcag/pull/775/files
<AWK> https://raw.githack.com/w3c/wcag/1405a037ca0483af7e423fc61fef74341cbdc525/techniques/html/H80.html
Alastair: I removed the example
and put in a fresh one.
... under the Newspaper Web site in Examples
... Replaces example that had a heading link and then a 'more
here' type duplicate link
... overlapped with H78. Kerstin thought it would be better to
have a more specific example that didn't overlap.
AWK: What was wrong with the original "more here"
Alastair: Because it has text with it that's part of the paragraph - so wasn't to do with the heading, but w/ the paragraph. That's where the overlap would be. The replacement example uses the heading as the link and uses a script to add a read more at the bottom.
AWK: Another approach would be to
get rid of the sentence after the heading and instead just have
a 'more here' link
... Either is fine - I take Kerstin's point
... Is 'box' the right word in the response? Maybe something
that clarifies that it's an additional paragraph.
RESOLUTION: Accept as amended
AWK: Three worksheets
... Overview is the sheet we're looking at
... We just approved Character Key Shortcuts - so updating that
in the spreadsheet
... From looking at this we're still lacking Techniques for 3
AAA SCs
... Timeouts, Target Size, and Concurrent Input
Mechanisms
... Still lacking Failure Techniques for several of these
... Anyone have updates that we'll see in the next week or
two?
<Detlev> I'll work on the F for 1.4.13 "Failure of content on hover or focus due to content not being dismissible"
Mike: Sent along a Failure for Status Messages, but it's looking more like a design issue - finding it very hard to fail.
AWK: So the question is "How would you specifically fail Status Messages"
Mike: Correct. I find it's more of a verbosity issue rather than a failure of Status Messages.
Detlev: Wouldn't you fail Status Messages if they exist visually but are not available programmatically?
Mike: As long as you have a way of ascertaining that something is a Status Message
AWK reading the definition of Status Message
AWK: An example - you add something to a shopping cart and the only thing that changes is the counter of the cart increases.
Detlev: I wouldn't consider that a Status Message. I would consider say you filter search results and it says something like "14 results shown". I think that's more of a Status Message.
AWK: I was keying in on the piece of definition that mentions how it shows the success of an action
<mbgower> That's likely more than a status message. it would probably be a dialog
Chuck: If you're bidding and the time expires, you get a msg that time has expired - that to me is a status message. BUT that's a result of inaction rather than action - so does that meet the definition.
AWK: Yes, but it also says 'progress of a process' - so it would fit in there
Mike: I think Detlev's example is much easier to come up with an example on
AWK: I will add the ideas we just came up with to the list
<AWK> AWK will add the ideas to the spreadsheet as options
AWK: We need people who can spend some time and volunteer to write a Failure. If everyone on the call would take ONE would could be done in a couple of weeks.
<Detlev> Just realise I have written a failure for 1.4.13! https://github.com/w3c/wcag/pull/450
<mbgower> There are lots of existing 2.0 SCs which do NOT have failure techniques. It may be that some of these just don't have/need a failure technique.
<bruce_bailey> please post the list again
Detlev: working on one for 1.4.10
Rachael: I have one ready to go - and I'll take on another one
AWK: For the SC proposals that we
have, this is our tracking spreadsheet. As you can see we're
still early stages. We've got SC requirements only for
Accessible Authentication.
... Any other updates that folks are working on for SC
proposals that they want to share?
... Want to make sure that smaller groups work on SC language,
docs, techniques and that the larger Working Group will
review
Jennie: I'm working on #15 "Find Help" - we're starting to work on the final half - testing and technique. But, Steve Lee is getting ready to go on vacation. Is there anyone else available that could help fill in on this one?
<mbgower> I can do an hour
Jennie: Even if I could get one hour w/ someone that would be great
AWK: I will take a look at it as well
<Detlev> https://github.com/w3c/wcag/issues/835
<Jennie> Thanks mbgower
Detlev: Reminder - I proposed a
new issue for Dragging that picks up where we left off with
path-based gestures
... We've reviewed it already on MATF
AWK: Will add it to next week's survey to get initial reaction from Working Group
<Zakim> alastairc, you wanted to say there is another potential SC as well, but no one working on it.
Alastair: There's another potential one: "Description for icons". Need someone to work on. Conceptually quite simple - and helpful.
<alastairc> https://github.com/w3c/wcag/issues/719
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/should like a non-contentious issue./seem like a good example to use, as it is contentious/ Succeeded: s/awk: proposed resolution would agree/RESOLUTION: WG agrees/ Succeeded: s/Does any one disagree?// Succeeded: s/./?/ Succeeded: s/F65/F63/ Succeeded: s/particuarly/particularly/ Succeeded: s/+!// Succeeded: s/or +1 even/+1/ Succeeded: s/Racheal:/Rachael:/ Default Present: AWK, Raf, Chuck, Jennie, MarcJohlic, Fazio, Laura, bruce_bailey, Detlev, MichaelC, SteveRepsher, stevelee, mbgower, Rachael, Glenda, ! Present: AWK Raf Chuck Jennie MarcJohlic Fazio Laura bruce_bailey Detlev MichaelC SteveRepsher stevelee mbgower Rachael Glenda Regrets: JF Jake Justine Found Scribe: jon_avila Found Scribe: Jon_Avila Inferring ScribeNick: jon_avila Found Scribe: marcjohlic Inferring ScribeNick: MarcJohlic Scribes: jon_avila, marcjohlic ScribeNicks: jon_avila, MarcJohlic Found Date: 30 Jul 2019 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]