<alastairc> https://www.w3.org/WAI/GL/wiki/Scribe_List#2020_Scribe_History
<ChrisLoiselle> scribe:ChrisLoiselle
<alastairc> https://github.com/w3c/wai-wcag-supporting-documents-redesign/wiki/Requirements-Analysis
<AWK> +AWK
Yes
Shawn: Scope of project is to design interface design to help make it relate to the WAI website. Broader scope is include on navigation and visual design
Supplemental guidance could also be included in this redesign , including aria authoring practices, etc. Determining the scope and purpose and objective of the redesign. Priority 1 is understanding and techniques.
<alastairc> https://github.com/w3c/wai-wcag-supporting-documents-redesign/wiki/Current-user-flows
The focus would primarily geared toward expert level knowledge of WCAG
Alastair: What would be useful feedback for this? Issue in github?
<hdv> issues welcome here: https://github.com/w3c/wai-wcag-supporting-documents-redesign/issues
Shawn: Yes. We want to make sure
AG input into requirements and scope. We'd like to know what
level and who wants to be involved as well.
... First, will look for comments and then number two, who
wants to be actively involved in the group.
Alastair: Does anyone think they may have comments?
Shadi: The user flows would be one thing to focus on. How do you and your colleagues use the documents? When and how do they look up techniques? What is relationship between understanding and techniques?
<Fazio> Many people don't know how to find them
DavidM: In general I may look at wcag tutorials and aria practices and not just techniques. Having the EO group involved is great. Any help to update techniques and incorporate the supplement (i.e. COGA) is useful to have.
<Fazio> +1 to DM
<shawn> [ hidde - let's note changelog ]
<hdv> +1 to ask clarification for changelog
Brooks: I support this work. I dig deep in the techniques and understanding documents. Anything that we can provide to users to get them into the details of this information is great. Perhaps a change log on informative changes would be beneficial.
<Zakim> AWK, you wanted to speak to removal of outdated guidance
AWK: There is a changelog. It is at the top of the techniques.
<Zakim> shawn, you wanted to respond to David and AWK on content & updateness
Removing a technique doesn't mean someone can't use it. Perhaps someone looking at "old" techniques is worthwhile, but is more for additional discussion.
Shawn: For EO, for scope, it is more visual design. Marking content for removal would need to come from AG.
<Zakim> hdv, you wanted to ask clarification about changelog and to say 'deal with outdated guidance' outside this project's scope (but we'll be more than happy to help design for
Hidde: Changelog question , where does this live?
<shawn> [ last updated ]
Alastair: Techniques index page. https://www.w3.org/WAI/WCAG21/Techniques/ then Change Log , A list of new, removed or significantly updated techniques:
<Fazio> is there an automated way of date tagging updates?
Alastair: Is their a cutoff date on comments for this for requirements ?
Shadi and Alastair: A week or two? Alastair: Two weeks would be great.
Shadi: End comments by the 25th of May? We can than look at comments by 26th of May for call.
Alastair: That sounds great.
<alastairc> Doc: https://docs.google.com/document/d/1WhZAbswvPHs7A3stfqM_ATsaBHPeGbHtARcmaKMck1U/edit#
https://www.w3.org/2002/09/wbs/35422/Visual_indicators/results will point to the SC text
<alastairc> https://docs.google.com/document/d/1SgwInDzCzJXJ9RZ9q5ktr3GxWYCTKkrmCInIdO4Qc10/edit#
Alastair: Will you be able to share what you have Rachael ?
<Rachael> https://www.fitbit.com/us/home
<alastairc> The proposed SC text is: "For each text-based control, spacing and/or font styling are not the only visual means used to convey that the control is actionable."
<Fazio> this cognitive requisite is what exacerbates fatigue
Rachael: When you start to look at the websites, the question comes up , are you looking at this in context ? Are the arrows text or not text? Do you treat them as text or icons?
I was looking at comparisons. Looking at CNN.com , does lack of a background lead to active indicator?
Rachael: Size is a different indicator. Should we add this into the SC? Use of color and spacing, should this be looked at? I.e. color and italic, should it pass?
Alastair: There are lots of variables. On fitbit, card type things where under carousel , the smart watches is a image, shop now and icon. There are things that look similar with no shop now. Within the variables we have, depends on context.
<Fazio> Most of the CNN example were page links instead of buttons though
On terms of survey results . Justine, is yours recent?
Justine: Yes. The user understanding the cues could cause issues on whether it is interactive or not.
<Fazio> That's why we discussed salience
The user would need to interpret a variety of cues
DavidM: Impact on visual design. We should publish with a note, asking for feedback on scoping, exceptions, font styling etc. Do we want responses from public to scope it for wcag 2.2 ?
I'd like to get as much COGA information in as possible.
<Zakim> Rachael, you wanted to point out Jake and Steve's examples
Alastair: If we do add a note , it may be viewed that its not entirely ready. Lets talk about the process view again.
Rachael: The example of the Facebook android app and the
post feature.
Seems to a good indicator of a failure.
<alastairc> https://material.io/components/dialogs
<Zakim> alastairc, you wanted to ask about process, whether that makes it not useful.
Alastair: The material dialog
boxes one is interesting.
... If we want to talk about process, would people be happier
with the success criteria?
<Zakim> AWK, you wanted to speak in favor of existing SC for use of color and concern about requiring something that is controllable with browser/extension setting, especially with limited
AWK: Having it constrained to a process, makes it more possible. I don't think a lot of sites meet the use of color. With links within the browser, there is ability to add underlines to links. We hear both that underline is beneficial and not beneficial to sets of users.
What constitutes success? Just because something is very big, does that mean it is interactive? If we recommend everything needs to be underlined, that may lead to pushback.
DavidF: I think constraining to a process is beneficial. I.e. buttons or links to move through a process.
We need to understand buttons and links. Buttons on processes and links on pages would be looked at.
Rachael: The concept of something being actionable is the affordance we started on.
<david-macdonald> For controls which are necessary to progress through a process, spacing and/or font styling are not used as the only visual means of conveying that the control is actionable.
Rachael: Limiting to process does constrain this.
Can we examine a broader example in next round?
<Chuck> +1 to reviewing a broader one next round
<Fazio> Would "buttons" exist outside of "process"?
<alastairc> Fazio - yes, could be buttons on a filter for search listings.
Brooks: Processes are one thing. Personalization is another. Say example of enhanced instruction. Is that part of process? What is "in" the process? What are we excluding?
SteveL: Rather within a process, talk to actions.
Yes, I can hear you Steve.
<Rachael> +1 to Steve. The original intel states "The purpose of this success criterion is to help people with cognitive disabilities or low vision to easily identify controls. "
SteveL: Things that trigger actions would be looked at for this SC. I.e. what is done with a link, what is done with a button. What is done for a dialog.
<david-macdonald> "For controls which are necessary to move forward or backwards through a process, spacing and/or font styling are not used as the only visual means of conveying that the control is actionable."
Alastair: Button vs. links in the wild, how would we define that unless it was within customization , perhaps in information and relationships.
<alastairc> Poll: Would you support this SC when it is scoped to a process?
<david-macdonald> +1
<kirkwood> +1
<Fazio> +0
<Chuck> +0
<GN015> -1
<Rachael> +1 if level A
<Brooks> +0
<JustineP> -1 still remain concerned about scope, implementation, etc.
If it helps +1, -1 if you don't support it. Supporting if it doesn't have a process included, please provide comment.
<JakeAbma> +0
<kirkwood> +1
<OmarBonill> +0
<AWK> +0
<david-macdonald> +1
<Detlev> +0
<Raf> +1
<Fazio> +1 if level A also
<JF> +0 with concerns
<Laura> +1
<Jennie> +1
Alastair: To Gundula , which aspects are you worried about?
Gundula: Wide implementations could lead to users being confused...
Gundula, let me know if I phrased that correctly. Thank you!
<GN015> no, i did not say anything, as was muted
<JustineP> that was JustineP speaking, Chris
Justine: Wide implementations could lead to users being confused.
<StefanS> -1
<Chuck> plus ones: 8, zeros: 7, minus ones: 2
<Fazio> +1 to wide review
Gundula: I feel what passes and fails , i.e. italics vs. not italics , the decision is not major and I don't feel like it is ready to go to public review.
<Fazio> We had a discussion of many salient factors and I thought decided that we would just require the use of more than 1
Alastair: The actual SC text is pretty narrow. The in scope variables are talked to within the SC. We can talk to whether we include other attributes in the SC.
Gundula: Talking to bold, bold is talked to an indicator and is also not, is the consensus that it is included?
Alastair: Fitbit examples talks to color and bold.
Stefan: The example presumes the active component is self evident. If we are looking at Gestault principles as a measure, Gestault principles may contribute to fact on what we refer to as active elements.
DavidF: We talked to salient factors. If we choose more than one, i.e. size, circular cues, movement, color may have been one too.
I thought that is where we were heading with this for design style.
<laura> Scribe: Laura
<ChrisLoiselle> Alastair: I agree that there are many factors that can be used, however it moves in to relativity of context . What are we talking to ?
AC: Compared to what?
DF: immediate surrounding
content.
... something we need to explore.
<Fazio> +1 to Stefan
SS: not so much the button or
link itsef but how it is embedded.
... list of links in the footer of a website.
... this is dangerous.
AC: your conclusion?
ss: not good if contenxt in which it is used.
dm: need a breakthough for
Gestalt principles.
... haven’t found a way to do this yet.
<alastairc> SC text: "For controls which are necessary to move forward or backwards through a process, spacing and/or font styling are not used as the only visual means of conveying that the control is actionable."
dm: advocate for putting the SC in.
<alastairc> Poll: Should we include this SC in WCAG 2.2 draft?
<Fazio> +1
<JakeAbma> +0
<Rachael> 0
<david-macdonald> +1
<Detlev> 0
<Chuck> 0
<kirkwood> +1
<Brooks> 0
<Francis_Storr> 0
<JF> 0
laura: +1
<AWK> 0
<GN015> -1
<pwentz> -1
<Nicaise> +1
<OmarBonilla> 0
<Fazio> no harm no foul in including it
<Chuck> plus one: 5, zero: 7, minus one: 2
<StefanS> -1
ac: not sure how to call this. more 0’s than support.
<JF> +1 to Chuck
<Rachael> plus one: 5, zero: 7, minus one: 3
ac: overall a +2 for a dozen responses.
DF: putting it out for the public may help.
<JF> +1 to Alastair - if close to half this group are unsure, it's clear that there aren't just a few outliers
ac: call for a deferment from 2.2.
<JF> s/putting it out for the pubic may help./putting it out for the public may help.
RESOLUTION: Defer, not ready for WCAG 2.2
<Fazio> :0(
AC: issue heavy.
<alastairc> https://github.com/w3c/wcag/issues/952
AC: can cover focus indicator if
tabbing through page.
... survey has split views on what to do.
... can you still have sticky headers?
... it may bring up other issues.
GN: maybe lost that point.
ac: may vary on scenario.
... depends on how high the content area is
gn: content in between can scroll.
dm: focus indicator gets lost it is a failure of 2.4.7.
jake: found this in testing.
focus gets lost. not sure how to remedy this.
... not sure if it should be a failure.
ac: maybe make the content the scrollable area.
mg: doesn’t say it needs to be in
view.
... slightly different thing. obscured or not in the
viewport.
Detlev: same way for sticky headers. lean toward not being a failure.
dm: wouldn’t fail it tabbing and can scroll down. It passes.
ss: affordance. is it an expected
thing?
... are there scenarios where this is expected? I can not tell
this.
ac: depends on scenario.
brooks: how much is the user supposed to know? that is the piece that is missing. not clerar.
ac: tricky one.
Detlev: as to affordances, it would be common for tab users.
df: if on person asks about some thing that may not be a problem if 2 ask it could be something. iso standard.
chuck: I would have called it a
failure.
... have techiques so it wouldn’t be a failure.
<Fazio> In ISO and Lean Enterprise 5S there are: Visual indicators, static (weak) Visual alerts, active (strong) Visual controls (strongest, (prevent errors
dm: sticky headers and footers diddn’t exist when we were writting this stuff.
<alastairc> acl da
dm: it is a partnership with how
much a user has to know.
... we can montor a situation. one outlier is not enough for a
big formal statement.
... it doesn’t fail if user can move with a simple action.
<alastairc> Poll: Would you have failed a sticky footer if it covered the focus indicator? (Assuming you can scroll down to see it.)
<david-macdonald> no WOULDN'T FAIL IT
<Fazio> yes
<AWK> No
<OmarBonilla> yes
<Detlev> no
<AWK> (but would highlight as needing fixing)
<alastairc> no
<KimD> yes
<Chuck> yes I would have, reluctantly
<alastairc> Mike: No reluctancy
<Brooks> Anyone vote for a failure of Focus Order?
<KimD> +1 to JF's terminology modification - failure is lost VFI
<OmarBonilla> +1 to that, too
<Nicaise> yes if user cannot readily find workaround
<Fazio> I need to understandas a visually and cognitively impaired individual highly problematic
ac: we have a mix.
<GN015> +1, if the focus hides behind the footer, no failure if the content scrolls above
<Fazio> problematic for short term memory loss
jf: problem is failing on a
visual thing.
... augmenting the chrome at the bottom of the browser.
ac: we need some examples.
... a failing one, a good one.
<Fazio> Adobe Acrobat editing and accessibility editing does this
<Fazio> sorry AWK
brooks: problem with sticky content. Sighted mouse user can use. Keyboard users doen’t have the same capacity.
chuck: swayed by dm.
... expert keyboard only user can use it don’t call it a
problem.
<Brooks> What about situational keyboard users, temporarily injured keyboard users? Will they know all these things they are supposed to know to overcome the hurdles we are talking about?
jf: android has see simplified view but it can be dismissed.
df: pdf has sticky footer that covers accessibility issues in thier checker.
<AWK> David, so this problem was in Adobe Acrobat?
ac: sounds like a different issue.
Detlev: browsers handle this
quite differently.
... this is more of a UA issue.
mg: clear we don’t have a good
way to fail it.
... worse experience for kb user.
... we don’t have guidence.
ac: we have an advisory technique.
<Nicaise> please include in the minutes link where one can find all the new SC's we've approved for FPWD since we're now done with new SC's.
ac: we could have an advisory
technique for this.
... will send a message to the list on this issue
RESOLUTION: Find some examples, leave open
ac: public comment.
https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues2/results#x1064
<alastairc> The focus indicator must not be time limited, when the keyboard focus is shown it must remain.
ac: (going through the comments.)
<Brooks> Does Concurrent Mechanisms tell us that folks should always be able to expect to use a keyboard, even if they've been using a mouse up to that point?
<Detlev> we are talking about kb focus only anyway, right?
GN: my point was that It must remain until another UI element receives the focus, and then it is shown with that other element.
ac: not sure that is saying anything diferent.
<Detlev> no objection, good response
ac: anyone object to proposed response?
<Chuck> no objections
<Francis_Storr> no objection
RESOLUTION: Accept response
<alastairc> Rachael: The COGA usable survey is open until wednesday, tomorrow.
<ChrisLoiselle> rrs agent, make 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) Succeeded: s/pubic/public/ FAILED: s/putting it out for the pubic may help./putting it out for the public may help./ Succeeded: s/indcator/indicator/ Succeeded: s/towearn/toward/ Succeeded: s/ir could /it could / Succeeded: s/couls/could/ Default Present: stevelee, Rachael, JustineP, Raf, alastairc, MichaelC, Fazio, Chuck, shawn, OmarBonilla, Brooks, Jennie, GN, Nicaise, AWK, JF, Pwentz, kirkwood, david-macdonald, KimD, Laura, Hidde, Detlev, JakeAbma, StefanS Present: stevelee Rachael JustineP Raf alastairc MichaelC Fazio Chuck shawn OmarBonilla Brooks Jennie GN Nicaise AWK JF Pwentz kirkwood david-macdonald KimD Laura Hidde Detlev JakeAbma StefanS GN015 Francis_Storr Regrets: BruceB CharlesH Found Scribe: ChrisLoiselle Inferring ScribeNick: ChrisLoiselle Found Scribe: Laura Inferring ScribeNick: laura Scribes: ChrisLoiselle, Laura ScribeNicks: ChrisLoiselle, laura 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: 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]