<ChrisLoiselle> I'm having audio issues, Hello Jeanne!

<ChrisLoiselle> Jeanne, I can hear, I just can't present my audio for you to hear me. I'll check my computer settings after the call.

<Lauriat> trackbot, start meeting

Pick out content to write at AccessU

<jeanne> color contrast

<jeanne> timing one suggested by Cybele

<jeanne> JF: THere has been an sctive discussion online to see whether the color contrast numbers in WCAG 2.1 are correct.

<jeanne> JF: Cybele makes a good point. WHat I heard was that we should have an example that is more subjective.

<jeanne> ... 1.1.1 could be an example of automated test, human evaluation -- could be scale example.

<jeanne> Denis: Color contrast: With a minimal numbers, then you can get minimal points. Better numbers, better score.

<jeanne> ... same with alt text - low score for "logo", better score for human verificiation

<jeanne> Cybele: WHen we start working on conformance, we will have the pieces ready for the examples

<jeanne> ... working on language, it would be helpful to have things we can test.

<jeanne> Jeanne: WCAG Usability Success Criteria research study <- https://docs.google.com/document/d/1ESlNcehaYoP8C3R_WSPkuuB17_c94cL6ih7ml4rpjsw/edit

<Cyborg> multiple ways to measure, emerging tech, personalization/customization, task-based assessment, overall guidance <--which current SC put these new aspects of Silver to the test, and can we work on the language of those SC during AccessU, so that we are ready with the examples when ready to move forward with conformance, architecture, etc.

<Cyborg> colour contrast <--benefit of that is that it can be one to test in future re: personalization/customization

<jeanne> jeanne: [looking at the list of learnability and ranked the hardest] we don't want the ones in Robust, because those will probably become methods. LEt's pick 1.3.3 Sensory Characteristics or 1.2.5 Audio Description (pre-recorded)

<jeanne> Cybele: asked about personalization (scribe didn't catch it all)

<jeanne> JF: The Personalization group isn't working at the level - [gives list of what Personalization is working on]

<jeanne> Cybele: One of the needs that the early discussion of where the needs of one group causes issues with other groups. Color contrast is the examples.

<jeanne> JF: We could do color contrast with existing techniques, the AAA could be worth more points, and the ability to re-skin the site so that the user can choose the color would be the highest number of points.

<jeanne> Jeanne: Recap what we have selected:

<jeanne> ... Color Contrast

<jeanne> ... Timing

<ChrisLoiselle> shawn talked to dataloss, interuption timing

<jeanne> ... Alternative text

<ChrisLoiselle> jeanne talked to audio description

<jeanne> ... sensory characteristics or audio description as an example of a hard one.

<JF> My idea around color is that AA (4.5:1) = "bronze", the AAA (7:1) = "silver", and the ability to "customize" the site colors = "gold" (whether that's through user-choice on alt "skins/CSS styles, of via a widget that allows more granular adjustments)

Scirbe: Chuck

<scribe> scribe: Chuck

Jeanne: I agree with Cybelle. Take an action item to look up those 2 and turn it into a list of what we are going to work on. Shawn and I discussed last week...
... We also made a list of how we were going to approach them. <computer issues>
... <slow computer>
... For each wcag sc, we'll evaluate user needs, test. Don't have to write individual tests, some are already written.
... Evaluate and prioritize difficulties. If doable we'll write methods and guidelines. Update style guide as we go and learn.
... That will be our process.
... We can move on.

WCAG to Silver migration

<Lauriat> https://docs.google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/edit#

Lauriat: As a part of that evaluating user needs, we are grouping together similar user needs. Color contrast in 2 sc's stem from same user need. One is 4.5:1 and one is 7:1. Grouping these together.
... Sometimes we are writing what the user need is, sometimes we thing we understand the grouping. We'll group together the ones that make sense.
... We will do another pass through to review. We'll declare the user needs for each one and write tests and such.
... We had just done label and name.
... Motion actuation.
... SC itself <reads SC>
... We've been setting aside exceptions to get to core user needs.
... Looks like 2 different things to me.
... <reads both items>... users can disable responding to motion to prevent accidental actuation.
... One of these is "make sure they can use things if they can't move device in that way", and the other thing is to ensure users can disable that if users tend to move the device in that way.

JF: A deliberate either/or?

Lauriat: Don't know if it's either/or or both. If you do second part you would need to do the first part.

JF: Been stressing scoring, I'm hearing bronze and silver.
... Ability to turn on/off is higher level of ability to change it.

Lauriat: and like some other things, like character key shortcuts.
... Scanning up to see what kinds of groupings... character key shortcuts we had 2 different groupings.
... One of the things that character key shotcuts has is "active only on focus", specific to a user interface component. Where the shortcut does something only when component has focus.
... This is more about desktop type interactions. There may be some overlap with motion. But I won't try to put these together yet.
... Just checking exceptions <reads exceptions>
... Next...
... 2.5.5 target size.
... <reads sc>
... 44x44 css pixels
... This brings up a lot of questions. Interesting to look at research behind the sizing.
... Interesting to see if there's a different size that would be better, or if larger would be detrimental.

Jan: I know there was months and months on this. We should get a copy of research. kathy walden was involved.

Jeanne: I was involved in the early days. This doesn't match original research, but that's ok.

Lauriat: We'll review research.

Jeanne: I'll find the research.

JF: Tons of discussion. Boiled down to android and ios.
... It felt circular.

Jan: Agree.

Lauriat: Apple's for ios say 44x44 and Android says 48x48 or something like that. Pretty close.

JF: Larger takeaways is that not only target size was important, but spacing between targets was important.

<KimD> (Kathy Walden = Kathy Walbin?)

Jeanne: When we work on this, we should not put a specific measure in the guidelines, and instead put that in the different methods.

Lauriat: Noteing what John says about space between targets.

JF: I think it may be one of the ones floating on the 2.2 list. Not paying much attention to master list. But I do recall this in the conversation.

Jeanne: Something that would need to be addressed in the methods.
... Whether or not to use pixel was a huge discussion. Differences on different types of displays. It's a complex issue. We should address details in the methods. We should have an overall guideline, but leave details in methods.

Lauriat: +1 to that, and meta-comment: This dimensions thing... we had this conversation in orientation and reflow grouping. Understanding doc for reflow helps people understand what it's suppose to mean.
... We can take what's in there and re-use it to explain.

Jeanne: This is going to be one of those examples that will be better in silver. We don't have to do true/false. We have flexibility. Will be helpful.

Lauriat: There's one more under input modalities. Concurrent input mechanisms. <reads sc>
... Not sure what "required to meet user settings" means. Anybody can explain?

Jeanne: What task force did this come from?

Lauriat: Not sure.

Jeanne: Then let's look at understanding.

JF: Repeat question.

Lauriat: 3 exceptions. Where restriction is essential, when it's required to ensure security, last one is "or required to respect user settings". What is that speaking to?

JF: In some ways it's extension of privacy/security question. When we say required to respect security, on server side, user settings on client side.

Lauriat: You lost me at server side part.

Kim: Thought this was about tablet with keyboard selecting, can interact with keyboard, shouldn't impact touch. Should be able to shut off tablet portion and use keyboard.

Lauriat: That's not content restriction. That's hardware.

JF: Sort of yes/no. AAA because it's blury. I think Kim was essentially correct. For example, from a security perspective if it requires signature on interface, we've seen that.
... That one right now... you can't sign using keyboard. Whether security/hardware issue it's reality. At AAA you should be able to to sign digitally as JF instead of physically sign.
... That's where that one was bubbling around.

Lauriat: This one to me essentiall is allow users switch modalities whenver they want.

JF: pretty much. Let the user be in control.

Lauriat: One is let user be in control, but I like about this sc is it could be mid-action. Say you start with keyboard on a big interactive list, you can switch to mouse if you see something further down, or visa versa.

JF: Yep, that's a part of it.

Jeanne: I would guess the user setting part is you would want to restrict accidental input from a modality you aren't using.

Lauriat: I think this is a good candidate for platform level guidance.

JF: yes, but it can also be controlled in part through content.

Lauriat: I wouldn't want to adjust my setting at every single web page.

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/conversaion/conversation/
Present: KimD ChrisLoiselle Cyborg Lauriat dboudreau jeanne bruce_bailey Shri Jan Chuck johnkirkwood
Found Scribe: Chuck
Inferring ScribeNick: Chuck
Found Date: 07 May 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.)