Accessibility Guidelines Working Group

21 Jan 2020


alastairc, JakeAbma, Nicaise, Rachael, Jennie, Raf, Fazio, jeanne, Chuck, CharlesHall_, KimD, janina, Detlev, Lauriat_, Laura, AndyS, jon_avila, Katie_Haritos-Shea, JustineP, JF, kirkwood, bruce_bailey, Brooks, mbgower
JakeAbma, Detlev


<JakeAbma> scribe: JakeAbma

<alastairc> https://github.com/w3c/wcag/issues/1003

<Detlev> I can scribe

<alastairc> https://www.w3.org/WAI/GL/wiki/Scribe_List

Silver, review of Editor's draft https://w3c.github.io/silver/guidelines/

<alastairc> Give another couple of minutes for people to get in

<alastairc> https://w3c.github.io/silver/guidelines/


<jeanne> https://raw.githack.com/w3c/silver/conformance-js-dec/guidelines/

Please look at the rawgit version

Jeanne: we've tried to simulate some of the features
... it's pretty rough, but focus on the structure and tell us if some parts are not ok
... the guidelines we've selected illustrate specifics to show how the guidelines might work
... most issues found was the structure, not the guidance
... the ones we've picked is to show how it works with migration of old SC
... contrast one is about new way of calculation, and how we will do it
... Clear Words is a COGA one not possible in 2.x, and we like to show how it might work and be measurable for Silver
... We really want feedback on Clear Words
... look at Clear Words, text now is: "Use common and clear words. Use lists of common words whenever possible. Remove unnecessary words. Unusual or new terms should have an easily accessed explanation."

<bruce_bailey> https://raw.githack.com/w3c/silver/conformance-js-dec/guidelines/explainers/ClearWords.html

Jeanne: you can see when you click on the link the structure for clear words

<Fazio> explanation link doesn't open for me

Jeanne: the "plan" tab is for product managers about planning responsibilities

<david-macdonald> @bruce THX

Jeanne: we want comments because it's new and contains planning, schduling etc.

<Fazio> I pretty much dig the interface

Jeanne: we have a 'design' tab, 'write', 'develop' and "test and Audit' tab

<Zakim> alastairc, you wanted to ask if there is (or will be) a separate explainer doc, keeping the spec itself concise.

AC: will there be an explainer doc?

Jeanne: yes, will provide link

<jeanne> https://raw.githack.com/w3c/silver/conformance-js-dec/guidelines/methods/Method-plain-language-principles.html

Jeanne: the methods will have a different design
... they need to look different from the guidelines
... we want it visually different, so you see it's a method, NOT normative etc.
... main page is about status and applicability

<bruce_bailey> right now explainer and methods have very similar visual presentation

<bruce_bailey> goal is for them to have distinct visual differences

Jeanne: If we look at test, you see an example of rubric
... liuke a grammer checker or speller checker where the check will determine how many points is scored

<Fazio> are we just looking at structure?

Jeanne: 1, 0.5 or 0

Jennie: looks good, very clean, are there reviews done on complexity of all the tabs

Shawn: no, not yet, it is too preliminary

Jennie: preliminary feedback can help usability concerns taken into account

DF: a bit confused on "partially meets"
... can they fail multiple boxes?, What does it mean for scores?
... what is I get a point 5 on one and another and another for total score

Jennie: will probably work like add up and devide
... a percentage is calculated
... tried to have a point system which doesn't dis-proportionally favor one disability over another.

Jeanne: we needed some samples and test with data

JF: there's no measurability here. How does it work like it is now?

<Fazio> JF - good point. What constitutes "some" errors

JF: how does it add up to a score with clear value

<Fazio> how many errors?

JF: how to apply to existent content
... concerning on the scoring and how to measure

<janina> Sometimes grammar erros do improve clarity. e.g. "He failed to completely understand it" is ungrammatical, but isn't the same meaning as moving "completely" elsewhere in that sentence.

AC: think it's good to see what stage we're at and what feedback to look for
... especially since we might compareold with new right now

Jeanne: we have roughly agreements on that points will become a percentage
... we're still talking about when you might fail, but we first need a score for a guideline
... you need a minimum per category, than a overall score, that a total

<Zakim> Lauriat_, you wanted to ask about JF's point, whether it has two parts.

Jeanne: it's tricky to do, still working on it

Shawn: John, you had two issues, need to be clear what you meant
... one specifically for the rubric
... like the grammer and for which part it is meant

JF: concern for measurability
... subjectivity on text for example is hard to get same results when 35 different people test something
... at minimum I like to see what we measure against

<Fazio> I've reached out to a colleague that's doing cognition research at Stanford to see if he can help us with this

Shawn: the context of the language question is important

<jeanne> https://raw.githack.com/w3c/silver/conformance-js-dec/guidelines/#scoring-conformance

links didn't work for me from the ducument

<Zakim> bruce_bailey, you wanted to ask about Silver request to WG members and timeline

BB: when do you need feedback on survey and process feedback

Jeanne: will be closed on Monday 27th

JF: .9, .25, .75 is that a good number, why 0, 0.5 or 1?

Jeanne: please share info so we will look at it

<jon_avila> I'd also add that even within a SC not all sub items are equal -- so some items in the SC would need to be weighted in the average.

Jeanne: we like more help from people and feedback

Important controls (re-review) https://www.w3.org/2002/09/wbs/35422/essential-controls/

<alastairc> https://www.w3.org/2002/09/wbs/35422/essential-controls/results

Rachael: original intent was to make it more easy for Coga people to identify controls
... asked Coga if persistent was enough for this SC as other issues poped up during creation of this SC
... Coga said 'yes' so now it is about persistence

<AWK> Current version: https://docs.google.com/document/d/1DPtCqWHjrhj3QZ4afsqzmWDd-zMSf39RsMqSpR2QGCg/edit#heading=h.ej41yvbs80dk

<Rachael> This was the original text: For main navigation and controls needed to progress or complete a process (essential controls), at least one of the following is true: 1) a mechanism is available to ensure essential controls are visible without scrolling or hover interaction the first time it is possible to progress after page load, 2) essential controls can be programmatically determined as being important, 3) essential controls are visually distinct from all o[CUT]

<Rachael> https://docs.google.com/document/u/1/d/1lUh2ZsQXRlC_S2gtJE5mMSIHEwB1K2gBBc0VL3hL4Yk/edit

DmD: can you gove example of controls appearing on hover?

Rachael: yes, there are some examples, sometimes hover, sometimes click

<jon_avila> Slack has an example of this to edit descriptions in channels.

DmD: so it's about flat design and no indicator?
... is visible affordances a bit the same, the other SC?
... we might combine them

AC: visual indicators = a control must have indicator
... persistent SC, not hide it, must be persistent vosible

<Detlev> Jake: Comment: is persistent = "always visible"?

<Detlev> Scribe: Detlev

jake: Does persistent clearly imply that it is always visible?

alastairc: Yes
... The aim is to require "persistently visible"

<Fazio> Good point

<mbgower> "persistent" does it for me. Easy to add in info in Understanding doc that it's talking about consistently visible

Jake: Understanding talks about hidden - which is a bit unclear

<CharlesHall_> persistence of visibility is also distinct from persistence in view

<Zakim> AWK, you wanted to ask whether exposing all controls would be overwhelming

<JF> +1 to AWK

<jon_avila> I had the same concern as Andrew that this could make it much more complex.

AWK: Concern when looking at WP page or editable grid - when things that appear on hover/focus are alway there, is that not sometimes a disadvantage, making things too crowded

alastairc: Would be a difficult sell for media player

<Jennie> WebEx, with Windows 10

AWK: Hovering over name gives mute button (in Webex)

<CharlesHall_> when WebEx is not the active window in the OS

<Fazio> same here

<Fazio> they disappear

<Fazio> #personalization!

Rachael: Does the setting option mitiagate those concerns (of too much cluttering)?

<Rachael> Controls needed to progress or complete a process are persistently visible or a mechanism is available to make the controls persistently visible except when: The equivalent control is persistent elsewhere on the same page

Rachael: If this SC is not doable this should go under personalisaton options

JF: agrees that personalisation path is the right path forward, currently not mature enough now

BBC VR focal points changes can induce nausea

scribe: that's why controls would only be visible when you look down

<Fazio> JF - good point

<Fazio> Makes this tricky

scribe: in some envisonments lie XR the requirement could be problematic

JF: We need to look at different use cases when crafting these

<Fazio> I guess field of view applies

alastairc: There is plenty of uncertainties even in narrower contexts
... like in editable grids, or editable pages

<Ryladog> I was going to say a mechanism is available

<Fazio> how about "point of use"?

alastairc: mechanism to turn controls on/off doable but feels like a triple A

alastair: personalisation possible but not clear which route

AWK: the mechanism might be good, some would want it to turn visibility of controls off

<kirkwood> Hidden controls need to be findable.

<kirkwood> (without memorization)

<alastairc> Kirkwood - have you considered the editable grids interface with a pencil icon next to everything?

AWK: not easy to be sure what the reaction would be if this is seen actually implemented, would need research
... that causes some discomfort

<Zakim> JF, you wanted to reference Personalization work https://w3c.github.io/personalization-semantics/content/index.html#simplification-example

JF: personalisation work: the closest thing applicable is an attribute about simplification - could set attrivute from critical to nice-to-have so all but critical stuff could be removed
... unclear whether group can meet review date

alastairc: Should it be marked at-risc?

JF: Personallisation - it's all about attributes, but nothing to map onto 'persistent'
... Could be tweaked to appear to meet that goal but not straightforward

<JF> https://w3c.github.io/personalization-semantics/tools/index.html

<Fazio> Inattentional blindness DescriptionAlso known as perceptual blindness, inattentive blindness results from a lack of attention that is not associated with vision defects or deficits, as an individual fails to perceive an unexpected stimulus in plain sight.

JF: when you look at this it's all about messages - a new attribute might be introduced to weigh iportance of controls to filter that for personalisation - but lots of ifs here

<Fazio> reasoning for this SC

JF: personalisation is about tagging things with inline metadata, so not ideal

alastairc: Visible controls as it stands feels possible but we would need to be sure it doesn't have a negative impact - a mechanism approach is an option but likely triple A
... if applied to important controls it could line up better

DmD: Easiest way to get this into current framework is to ensure that every control has a proper role to give the user some control for turning it on or off

<JF> The 3 modules that Personalization TF are working on here: Personalization Semantics Content Module 1.0 - https://w3c.github.io/personalization-semantics/content/index.html Personalization Help and Support 1.0 - w3c.github.io/personalization-semantics/help/index.html Personalization Tools 1.0 - https://w3c.github.io/personalization-semantics/tools/index.html

DmD: Full persistency might appear distracting - designers may be forced to design to designs, one with and one without persistent controls

<JF> We've been focused on the first module (Semantics Content Module) - the other 2 are less mature

DmD: may get pushback from design community

alastairc: is it worth continuing with the persistently visible controls aspect? What do others think?

<Fazio> +1

<AndyS> -1

alastairc: +1 if you think it is useful

<Ryladog> +1

<david-macdonald> -1 For requiring contorls visible or a mechanism

<AndyS> Needs to be user configurable

<AWK> -1

<bruce_bailey> -1 sorry, don't feel like we can make this work for 2.2

<mbgower> +1

<JakeAbma> 0


<JustineP> 0

<laura> 0

<Jennie> +1

<JF> -1

<CharlesHall_> -1 but only because i like the idea of combining with the other SC

<Brooks> -1 Love the concept, but it needs more discussion and research

<AndyS> Small screen real-estate makes persistent controls a non starter

<Fazio> Inattentional blindness DescriptionAlso known as perceptual blindness, inattentive blindness results from a lack of attention that is not associated with vision defects or deficits, as an individual fails to perceive an unexpected stimulus in plain sight.

<kirkwood> +1 this is a complex issue, vanishing controls is an issue. getting to controls may be the issue

<bruce_bailey> i like concept too, i just dont think we can get it nailed down for 2.2

<KimD> -1 bcs needs the research around implementation as AWK suggested

alastairc: (summarising points above) what point are you meking David F:

David F: if you are not expecting a control, it is more difficult to anticipate / bring up

David F: Critical thing is point of use - if you need them you should see them

alastairc: that is the reson why interfaces hide controls
... would create a very noisy page
... often good reasons to hide stuff

David F: Is it a parent control approach?

<kirkwood> something to indicate that controls are available without actually showning the ontrols.

alastairc: Could allow that

David F: Worth exploring more

alastairc: Limited time frame for 2.2

<AndyS> The problem with AR and HUDs and nausea is probably most similar to problems we have here in Hollywood relating to 3D stern films., where the divergence causes a lot of motor-work by eye muscles. This is not an issue for a mono screen with a single focal point.

alastairc: mixed responses - Mile why your+1?

<AndyS> The problem with persistent vs disappearing controls is the complexity of the context sensitivity of use, where a bright line is not definable.

mbgower: Unsual to remove a control entirely - people move away from removing controls entirely
... a potential path is adding the ability to make controls persistent if they aren't

<AndyS> I have some apps with some persistent controls that are there from the "marketing" department, that makes th app nearly unusable.

alastairc: Rachael included the 'mechanism-is-available' aspect
... unclear how feasible it is though

mbgower: Wants examples for problems when things are persistent

<AndyS> Controls are per haps the most context sensitive of content types.

<Fazio> put "essential controls"?

Brooks: likes this enough to improve it to make it a thorough SC, quite in favour of the concept, but needs more work

<Fazio> "persistent essential controls"

<kirkwood> +1 to Brooks

<AndyS> Context sensitivity points are unintended consequences...

alastairc: We need to get this ready or postpone in next two weeks
... public working draft is useful but we need to give it more thought first

<AndyS> At Fazio: how do you define "essentiall" ?? That's a context problem

<AndyS> Okay thank you

Charles: Can we leverage the time invested and propose a combining of essential controls and visual indocators (since they overlap)?

alastairc: this is about seeing that something can be interacted on, the other to indicated clearly - may niot be enough time

DmD: Visual indicators - mechanism idea id interesting - can we require author sto inform users on the purpose of a control? But there is overlap

alastairc: not sure where to go with this one - maybe focus on the programmatic aspect (correct roles) gives plugin opportunities - otherwise need a lot of research in little time to see whether mechnism approach would work

<alastairc> "Controls needed to progress or complete a process are persistent or a mechanism is available to make the controls persistent except when:"

alastairc: 'mechanism available' aspect would not work in a media player context - may have an exception for overlapping content

RESOLUTION: leave open

Touch target spacing https://www.w3.org/2002/09/wbs/35422/target-spacing/results

<AndyS> Overlapping content is a problem with the LYFT apps due to marketing shoving things in that cover other things (like Monty Python)

<alastairc> https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#

alastairc: (going through survey results)
... overlapping issues with dropdowns...
... values seem to have been updated
... anyone can explain history
... if less than 44 it needs to be 52 with margin - what#s the rationale?

Jake: We changed it because of Alastair's comment about tabs (wide controls not quite meeting height criterion)
... so in this wording the offset would not be needed, that's why the total (for target width and margin) came up

<alastairc> Example page:

<alastairc> https://www.w3.org/

Jake: because spacing for larger elements is not needed - only where one dimension goes below 44px

<CharlesHall_> i think the wording could improve to match that description, but +1 to the description

alastairc: Example helps - lefthand links would be in scope, would need to be taller

<CharlesHall_> regrets, I have to drop off the call.

alastairc: would need 15 px more height. Links in middle sectino probably OK because they are inline

on the right there is a mix of inline and others

(alastairc and Jake discussing example on w3.org)

alastairc: discusses difficulty of separating inline and not inline

Jake: Amazon site is a good example
... almost fine, a few pixels missing (increase from 42 to 44px)

DmD: asking about 52

alastairc: it's just about one dimension of the target
... if it is, say, 26 then the spacing would have a total of 26 as well

Jake: TF arrived at 52 - you make target bigger or add space

DmD: discussing example with too little height

alastairc: for any target you would want to check if the total of target height (or width) plus margins add up to 52

DmD: Some interfaced like to crowd get a lot of things into one view

alastairc: Looking at target size (triple A)
... this one has the same feasibility issue, but a bit more flexible - would conflict with common toolbars in applications
... anyone else having concerns?

DmD: language feels a bit confusing

alastairc: Examples would help
... Are we as a group happy to put this up for wider review? It would impact lots of interfaces- does it provide good benefits without making interfaces worse for anyone else?
... no concerns?

DmD: The trouble from before is the big impact on visual interfaces, not sure...

alastairc: there is more flexibility but this impact is there

<Zakim> mbgower, you wanted to say what about afull page view of a web page?

mbgower: Web page on mobile browser with reduced size - is that failing?

alastairc: this site would fail reflow, but this is a zoomed-down version
... we are testing content as authored, not the zoom level - zooming in and getting bigger targets would also not be a way of passing this SC
... other concerns?
... So is this right at double A?

DmD: Should make editorial changes to improve understandability

<jon_avila> Seems like "inline" need to be a part of the SC text and not just the understanding.

alastairc: happy with further editorial pass, but little time - are we happy conceptually?
... happy to put up for wiser review, but expect pushback
... David gt in touch with Kathy and MATF to make editorial changes

Bruce: is there space for the March meeting?

alastairc: we need to pin down times within these dates

Bruce: offers space in Washington DC for face-to-face

alastairc: Thanks everyone - agenda for next week ready

<alastairc> https://www.w3.org/WAI/GL/wiki/Upcoming_agendas

Summary of Action Items

Summary of Resolutions

  1. leave open
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/01/21 18:02:26 $

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)

Succeeded: s/the methods have a different design/the methods will have a different design/
Succeeded: s/work for 2.1/work for 2.2/
Default Present: alastairc, JakeAbma, Nicaise, Rachael, Jennie, Raf, Fazio, jeanne, Chuck, CharlesHall_, KimD, janina, Detlev, Lauriat_, Laura, AndyS, jon_avila, Katie_Haritos-Shea, AWK, JustineP, JF, kirkwood, bruce_bailey, Brooks, mbgower
Present: alastairc JakeAbma Nicaise Rachael Jennie Raf Fazio jeanne Chuck CharlesHall_ KimD janina Detlev Lauriat_ Laura AndyS jon_avila Katie_Haritos-Shea JustineP JF kirkwood bruce_bailey Brooks mbgower
Regrets: SteveL
Found Scribe: JakeAbma
Inferring ScribeNick: JakeAbma
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Scribes: JakeAbma, Detlev
ScribeNicks: JakeAbma, Detlev

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: 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]