COGA 9 April 2020

09 Apr 2020


Rachael, stevelee, Abi, Jennie, Fazio_
EA, John, R


Review user story changes and restructure https://raw.githack.com/w3c/coga/changes-after-0327/content-usable/index.html

<Rachael> scribe: Abi

Rachael - we have switched the order of the document: introduction, design guide. The user testing sections in the design guide has moved to the testing section.

This means that the sections aimed at designers are grouped together

<Fazio_> present

<Fazio_> +

<stevelee> +1

Is everyone ok with this structure?

<kirkwood> +1


Rachael: reviewed mental health and way-finding sections. Re-ordered and added some examples. No new patterns added

John and Steve worked on way-finding. Have merged some suggestions into the patterns. It will be merged into the github version very soon

Rachael: need any changes in the design patterns to be merged by end of tomorrow so that they can go out to review

David: we would like to add more content in relation to mental health but need more evidence. Have added in some content about distractions, concentration and anxiety to existing patterns

<Rachael> https://www.w3.org/WAI/GL/task-forces/coga/wiki/PlanningPage#updated_time_line_-April_2020

<Jennie> Sorry I will type

Rachael: next step is an editorial review by April 16th.

<Jennie> Can you tell me which day we would get the link to start reviewing?

<Jennie> But isn't there a date to start?

<Rachael> https://raw.githack.com/w3c/coga/changes-after-0327/content-usable/index.html

<Jennie> Perfect, then yes, I can review by the 16th

Rachael: it will be ready to start the review tomorrow

<Jennie> How are we handling proposed edits?

John K: better if everyone has visibility of comments and edits in a document rather than in emails.

<Jennie> I am fine editing however works for everyone.

Steve: if would be good to have opportunity to cross-review

<Jennie> +1 to Steve's proposal

+1 to moving it into google dox

Rachael will send link with instructions on how to review to the COGA group

<Jennie> *snow storm seems to be impacting my mic, will try switching headset/mic

Discussed in the AG meeting this week

<Rachael> Current SC Text: Visual Indicators: For controls needed to progress or complete a process, and inline links in a block of text, differences in spacing between elements, typeface, font size, or font style are not used as the only visual means of conveying interaction.

<Rachael> Exception: An underline is a sufficient indicator that a control is actionable.

<Rachael> https://docs.google.com/document/d/1WhZAbswvPHs7A3stfqM_ATsaBHPeGbHtARcmaKMck1U/edit?usp=sharing

<Rachael> Pattern: 3.2.6 Pattern: Use a Design that the User is Likely to Recognize and Understand

David F read response to AG focusing on known control designs

Steve: concerned that this has diluted the COGA design needs
... new SC text states what i can't do but not what i need to do

<Rachael> Abi: I am confused by the new wording. I don't know what it means by elements. If testing, there is nothing I should be looking at buttons or a type of control. It seems mixed up with text.

<Jennie> +1 to interactive elements

<Rachael> Steve: Would interactive elements address that point?

<Rachael> Abi: I was looking at the list and it seems to be going around with personalization. The AG group hasn't acknowledged the main reason for this is touch screen and lack of AT use.

<Rachael> David: Hover leading to fatigue.

David F: it is very fatiguing having to search for actionable controls

<Rachael> Abi: I wanted to add I think it is good that text links are considered because it is a gap in the current SC. There isn't a requirement that links are underlined. So that is good.

<Rachael> I found that difficult last week. Not worded. well.

*yes please

<Rachael> kirkwood: I'm not sure why this is different than any other control.

<Rachael> Rachael: Scoping used to address front of web sites like amazon

<Rachael> Kirkwood: If we are talking about making something apparent in a process vs making something apparent period, I don't see the uniqueness of this compared to any visual indicator. Maybe it should be more unique.

<Rachael> ....I don't think the AG quite got that either. I'm unsure how to handle that.

<Rachael> Possible Draft: For interactive controls and inline links in a block of text, differences in spacing between elements, typeface, font size, or font style are not used as the only visual means of conveying interaction.

<Fazio_> It was also asked if the scope should be broadened during the AG call

<Jennie> https://www.w3.org/WAI/WCAG21/quickref/#sensory-characteristics

<Rachael> Jennie: If we look at 1.3.3 for its vocabulary. The concept is the opposite of 1.3.3. Instead of not relying on sensory characteristics alone, reverse it to rely on some sensory characteristics alone.

<Fazio_> +1

Examples at https://docs.google.com/document/d/1fw8C-uHkPzI9IH4wWXdzjRmyfxTHNIYX3vk62Xsph4M/edit#heading=h.ck57f2kxzytg

<Rachael> abi: Specific question about examples. I did some earlier in the year. I will put the link into the google doc now.

<Rachael> Steve: The SC text doesn't quite capture the need.

<kirkwood> +1 to Steve’s ?

<Rachael> ...open question about process?

<Rachael> 1.3.3: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. (Level A)

<stevelee> Here's the understanding

<stevelee> The intent of this Success Criterion is to ensure that all users can access instructions for using the content, even when they cannot perceive shape or size or use information about spatial location or orientation. Some content relies on knowledge of the shape or position of objects that are not available from the structure of the content (for example, "round button" or "button to the right"). Some users with disabilities are not able to perceive shape or

<stevelee> position due to the nature of the assistive technologies they use. This Success Criterion requires that additional information be provided to clarify anything that is dependent on this kind of information.

<Rachael> proposal: Interactive controls do not rely solely on spacing or text characteristics, with the exception of underline, to differentiate it from static content.

<scribe> scribe: Abi

<Jennie> Ah, thank you for clarifying @David Fazio!

David: the reason for adding the exception for text underline is to ensure that links that are underlined to not fail

<kirkwood> would this force underlines?

<kirkwood> interactive elements

"single characteristic"?

<Rachael> Interactive elements do not rely solely on spacing or text characteristics to differentiate them from static text. Exception: Underline for links

<Jennie> Maybe with the exception of underline for links?

<Rachael> Abi: Scenario I'm thinking of would be bold and color change to indicate a link, it would fail. Is it a single text characteristic.

<Rachael> Interactive elements do not rely solely on spacing or single text characteristic to differentiate them from static text. Exception: Underline for links

<Jennie> Love specifying a number of characteristics - maybe visually identifiable characteristics?

<Jennie> +1 to Abi's concern

<Rachael> Abi: Would this apply to icons and non text controls?

<Rachael> Interactive elements do not rely solely on spacing or single text characteristic to differentiate them from static elements.

<kirkwood> thihnk single text characteristic. so color is not good?

Steve: elements need to be defined as controls and links

JohnK: this would require that only colour couldn't be used for links

<Rachael> Is this new text good enough to represent a cognitive need?

<Rachael> Abi: Original intent was around butttons without borders that look just like text. Kiosk interfaces where what is text and what is a button?

<Rachael> I can see that the text fits into it but if its an icon, a home icon, how does that fit in?

<Fazio_> +1

<Rachael> abi; May need graphic elements as well.

<Jennie> Interactive elements do not rely solely on spacing or single visually identifiable characteristic to differentiate them from static text. Exception: Underline for links


David: Talking through examples where a visual indicator is used on interactive and non-interactive elements
... will share link and examples

<Rachael> concern about disabled icons

<Jennie> Rachael - that example should go in the understanding document.

<kirkwood> not comfortable with that

<Fazio_> spa site link https://www.sba.gov/funding-programs/disaster-assistance

<Rachael> abi: In early discussions we had an exception for groups of elements.

Rachael: often the only difference between disabled and active icons. But as group agreed that this would be ok as the disabled icon will not be covered by SC

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: 2020/04/09 15:02:42 $

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)

Default Present: Rachael, stevelee, Abi, Jennie, Fazio_
Present: Rachael stevelee Abi Jennie Fazio_
Regrets: EA John R
Found Scribe: Abi
Inferring ScribeNick: Abi
Found Scribe: Abi
Inferring ScribeNick: Abi

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

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]