<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
<alastairc> Give another couple of minutes for people to get in
<alastairc> https://w3c.github.io/silver/guidelines/
<AWK> +AWK
<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: 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
<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 39.7.7.27, 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
-1
<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
<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
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]