scribe HarrisSchneiderman
<scribe> scribe: HarrisSchneiderman
https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-01-17+
carmacleod: sounded reasonable to me and she backed it up
jamesn: does anyone know the history of why we don't have aria-description?
mattking: It was supposedly duplicating title, which is weird because title is now technically a fallback for name
jamesn: it'd fit into 1.3 as attribute parity (doesn't fit our 1.2 scope currently). Make sense?
jamesn: level access have
graciously offered to host us in our f2f in the spring
... the dates we are currently looking at april 30th - may 2nd
(tues - thurs)
... Level access's office is downtown SF
<jamesn> 114 Sansome Street
jongund: I can probably just join remote - don't change dates on my behalf
jamesn: are these the final dates?
melanierichards: I can come
<melanierichards> (edge)
jamesn: We will reach out to
james craig
... hopefully someone from mozilla
jemma: What is the goal of this f2f?
jamesn: To get as much role parity work done as we can
carmacleod: Do we want to pull in screen reader developers?
jamesn: anyone in wg is obviously
welcome to come, or anyone who will add significant value
... We're hoping that having it in SF will make it easy for
google and facebook folks to join
... we will reach out to everyone once we have the set
dates
https://github.com/w3c/aria/pull/888
<jamesn> https://raw.githack.com/w3c/aria/meter/index.html#meter
joanie: I'm going to present some of these points out of order because some don't need explanation and some do
<joanie> An element that represents a scalar measurement within a known range, or a fractional value. See related progress.
joanie: The first statement (of role description) I basically just listed it as it is described in the html spec
<joanie> Authors SHOULD NOT use the meter role to indicate progress; the progressbar role exists to address that need.
<joanie> Authors MUST NOT use the meter role to represent a value whose minimum and maximum values are unknown and MUST use aria-valuemin and aria-valuemax to make these values available to assistive technologies.
joanie: if it doesn't have a
range then it is not a meter at that point
... Anyone want to debate/discuss this 3rd statement?
mattking: meters arent interactive, right?
joanie: right
<joanie> At the present time, there are no WAI-ARIA properties corresponding to the low, optimum, and high attributes supported on HTML meter. The addition of these properties will be considered for ARIA version 1.3.
<joanie> Authors wishing to communicate that the displayed value is low, optimum, or high SHOULD do so by including this information in aria-valuetext.
joanie: I think we can have
accessible meters without the above attributes
... I'm picturing "Optimum: {value}"
jamesn: Its not ideal but a good interim solution
joanie: There often is an indication on a native meter that you're in the right spot
jamesn: theres no info being communicated on how close you are to optimum
mattking: you only that you are in one of those ranges
jamesn: html knows how close, its just not being communicated
mattking: I just wonder if there
is a better way to express that
... Is there a visual indication of these ranges?
jamesn: If you were to at all the
time expose this info to AT, it'd create a rather verbose
experience
... if we were to communicate all the info that a meter
exposes, it'd be a lot
mattking: to expose 3 separate
ranges, it'd be a non-trivial amount of attribute work. So the
idea of postponing it is interesting
... we'd introduce the role with suboptimal accessibility
jamesn: the difference is, the attributes that are currently there don't have any accessibility mappings from native meters
mattking: so they don't have any way of exposing these to accessibility APIs
joanie: not entirely
... my platform _will_ have a way to expose these
attributes
mattking: We could open issues against those other APIs - we're going to want to express these 3 ranges (low, optimum, and high). And we're going to need these in the 1.3 timeframe
joanie: we can take a look at what the html mappings are and how ATs handle this - I don't know. We should take a look first
jamesn: I Don't think we need min and max
mattking: there are 2 points
within the overall range in which we could say this is where
you are in the low min cuttoff
... my concern is that we tell them to do this now with
valuetext and then tell them to do this differently later in
1.3
... we'd have to teach it and then unteach it
<joanie> Authors wishing to communicate that the displayed value is low, optimum, or high SHOULD do so by including this information in aria-valuetext.
joanie: I'd like consensus on - should we delete this (above) statement?
mattking: I'd rather not have
that in the spec
... we could consider adding a provisional statement to aria
authoring practices as a "temporary hack" to ensure people
don't see this as a thing they bake into their system
... unless they are prepared to changing how they do it in the
future
joanie: we've got this thing that is not interactive - its a lot like a progressbar. I've made the new meter element a subclass of the Range role (which is a widget)
jamesn: I've worked on many many products that have interactive meters
mattking: could those have been something that is not a meter
jamesn: you couldn't type in a value but rather alter it with up/down arrows
mattking: I don't like when
things inherit from both sides of the tree. when something
isn't interactive I don't think it belongs within widget
role
... ranges don't necessarily have to be interactive
... I guess (thinking outloud) I am in favor of
dual-inheritance
... we could approach it like separator. Did we add multiple
inheritance there?
joanie: it does (it inherits from both structure and widget)
mattking: it is a mutually
exclusive form of dual inheritance
... the only way to do that with this is to make range a
subclass of structure rather than widget
joanie: I am totally cool with
doing that
... if so, then I'd assume we want to make meter block on
making the taxonomy change
mattking: I'm thinking in the
future we might get rid of taxonomy somewhere down the road.
Given that, we'd not have meter in the widget role class
... its not parity if we say that it is an interactive
element
... toolbar is a structure that we treat like a widget
... getting things right here is important
joanie: is progressbar / slider going to have mutliple inheritance too?
mattking: and meter would have
single inheritance from range
... you can make structures focusable - they're just not
interactive
jongund: does html make it
focusable though?
... people would look at the native implementation to decide if
it should be focusable
stefan: Things like meter when
focusable are often the starting point to a drill down
... you can definitely have a focusable meter - with a click
handler and use it as a sophisticated button? This is a
grey-zone, is it allowed or not?
mattking: I think it should be allowed but I don't think we need to address in the spec
<joanie> https://github.com/w3c/aria/issues/892
joanie: the last question is: are we cool with meter? if so, do we merge now (into editors draft)? or do we wait for range subclass work to land first?
jamesn: We should delay/block
https://github.com/w3c/aria/pull/886
jongund: The main issue with this is, whether or not this will be taking in consideration in actual label calculation
<jamesn> https://pr-preview.s3.amazonaws.com/jongund/aria/pull/886.html#label
jongund: If you encapsulate a
widget in an element with role=label, will that be the
element's label
... With a native label, if you click on it, it moves focus to
associated control
mattking: we usually address this
with an "Authors should..." statement
... the spec needs to make that clear
... this is equivalent to statements about managing focus
... it wouldn't be a note, just and "Authors should"
statement
jongund: should it become integrated into accessible name calculation (similar to how native labels work)
jamesn: there is an acc name
issue for this
... I'm concerned about "authors should" statement
... the html spec says this behavior should match the
browsers'
<jamesn> The label element’s activation behavior should match the platform’s label behavior. Similarly, any additional presentation hints should match the platform’s label presentation.
mattking: I wonder if there is potential for conflict between label and aria-labelledby
jamesn: of course there is
... We will put this back on the agenda next week
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: MarkMcCarthy, melanierichards, janina, HarrisSchneiderman, jamesn, MichaelC, Stefan, jongund, Bryan_Garaventa, jemma, mattking Present: MarkMcCarthy melanierichards janina HarrisSchneiderman jamesn MichaelC Stefan jongund Bryan_Garaventa jemma mattking matt-king Found Scribe: HarrisSchneiderman Inferring ScribeNick: HarrisSchneiderman WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 24 Jan 2019 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]