<scribe> scribe: harris
jamesn: 1.2 doc out the door for
review. hopefully early 2nd quarter it'll go through all the
process. We're not too far behind schedule
... going with the original schedule for 1.3
jamesn: confirmation from facebook that they can host - May 5th through 7th
<MichaelC> https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2020
<Jemma> https://www.w3.org/2002/09/wbs/83726/2020-05_FtF/
https://github.com/w3c/aria/issues/1144
jamesn: i think it was a hint to
look at the structure. I think we should just move it to 1.3
and remove it
... If you disagree state that in the PR
https://github.com/w3c/aria/issues/1143
jamesn: we need to fix this ASAP for 1.2
https://github.com/w3c/aria/issues/1141
jamesn: do native scrollbars give that info?
joanie: not that I'm aware of
Scott_O: I don't think this is something we want to expose
jamesn: I fear it is more info that most people get out of a scrollbar anyway
Scott_O: it'd communicate info about the height of the actual scroll bar
jamesn: how about we say: "Once native scrollbars start conveying this info, we will address this"
sina: in native, a scrollbar
actually convey this info
... for example, whatsapp, I'm in a chat (previously we had
page up / page down), VO in IOS has a scrollbar widget towards
the end of a screen (it is the right most edge). If you touch
anywhere there, you can flick up and down and increment of
10
joanie: that is not what this
ticket is describing
... when I visually look at the scrollbar, there is a thumb and
the top of it and one at the very bottom. The shaded part of
the scrollbar occupies about 75% of the total scrollbar
area
sina: that affordance of 75% should be exposed to a screenreader
jamesn: the value is where it is
currently scrolled
... as well as the viewport size
sina: on native ios scrollbar you
hear "20%" and a page count of some sort
... agreed. there are 2 key pieces of information here
<pkra> I vaguely recall talkback giving an audio cue when scrolling a web page.
<pkra> starting a low frequency and increasing.
lazy load will create some interesting readouts...
https://github.com/w3c/core-aam/issues/59
<pkra> (just retested -- seems to still do that)
https://github.com/w3c/aria/issues/1140
jamesn: we already have PR for this
joanie: will this require a wide review?
MichaelC: If its not a huge change then we don't need an additional wide review
https://github.com/w3c/aria/issues/1139
<joanie> joanie: I want to include issue #1140's fix in 1.2.
jamesn: this is essentially edits
to the merge
... this is a 1.3 feature. It isn't something that will
immediately be in ARIA
<jamesn> https://github.com/w3c/aria/pull/1133
jamesn: we've had some comments on the language recently
joanie: my concern with role parity is that we don't want to have questions on "does the role cover the html equivalent"?
<Jemma> https://github.com/w3c/aria/pull/1133#pullrequestreview-338890932
<Jemma> aaron's comment
<pkra> why does it say "The mark *element* ... " ?
<pkra> (my mic isn't working)
jamesn: once aaron fixes that, it would be awesome if others could review
<pkra> ebooks (even PDF viewers) can highlight...
<Jemma> ;-)
webex crashed :(
<jamesn> https://github.com/w3c/aria/pull/1136
Aaron: I have communicated to JAWS/NVDA authors about having multiple details (via aria-details), they are saying it is non-trivial to write this code but they are willing to put in the work to support it
joanie: it is in progress and I am totally in favor of it
jamesn: What about voiceover?
Aaron: I was going to gather the
nvda/jaws/orcha info before reaching out
... same goes for chromevox
https://github.com/w3c/aria/pull/1136/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR10728
Aaron: is aria-describedby used in accName calculation?
jamesn: I'd like matt to be on the call before we merge this
<Jemma> I assigned Matt to this issue so that he can give attention.
<Jemma> and feedback
joanie: what about aria-describedby and aria-details?
aaron: My intention is that they can both exist.
<Jemma> can we document what Aaron is saying about the relationship among ria-describedby and aria-details?
aaron: imagine a flat text annotation but you also need to have a comment on it
jamesn: if you're annotating an interface that is already using aria-describedby for an inline error then I can't use an aria-description because it'd get overridden
aaron: for that, to have multiple
flat text descriptions you'd just have to use multiple
aria-describedby token list items (item IDs)
... describedby would take precedence over description
jamesn: we will merge this sometime around next meeting
<joanie> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/1136.html#aria-details
Jemma: what is the plan as far as where this will be documented?
jamesn: this is the first step.
we will, at a later time, update others (core aam, APG,
etc..)
... joanie and I create wiki entries for what all needs to
happen
<jamesn> https://github.com/w3c/aria/pull/1137
carmacleod: we should state that this isn't rendered visibly
Aaron: no aria attribute is
... I copied the conventions of aria-label
joanie: What I was hearing was "sighted users don't get aria-label", is that what you were saying?
carmacleod: yes. aria-label
touches on visibility a bit more
... we should tell the devs out there that this won't show
up
<carmacleod> https://w3c.github.io/aria/#aria-label
Aaron: maybe if anything we should update some of the general text that "no aria attribute will alter anything visibly"
<joanie> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/1137.html#aria-description
joanie: I think aaron is trying to do that - "If the description text is available in the DOM, authors SHOULD NOT use aria-description..."
carmacleod: people overuse aria-label so I want to avoid misunderstandings here
sina: I don't think that the misuse is driven by misunderstanding of visibility
<jamesn> https://github.com/w3c/aria/pull/1147
aaron: this is something that
came up was a term/definition. When I looked it up it said to
use aria-label which I think was an oversight
... the label would replace the inner text
see https://github.com/w3c/aria/issues/1117
Scott_O: I assumed this was defining how a group was named. I'm all for this
<jamesn> https://github.com/w3c/aria/issues/1139
solution 1: aria-live="assertive" is used in this example instead of polite because the error message should be read before the user finishes the field and tabs to next field where the previous error message may be confused with the next field's message?
<Jemma> welcome Sina!
https://github.com/w3c/aria/issues/961
<pkra> bye
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/include this/include issue #1140's fix/ Succeeded: s/ity/it/ Default Present: carmacleod, harris, Joanmarie_Diggs, MichaelC, pkra, Scott_O, tzviya, MarkMccarthy, CurtBellew, Jemma Present: carmacleod harris Joanmarie_Diggs MichaelC pkra Scott_O tzviya MarkMccarthy CurtBellew Jemma Found Scribe: harris Inferring ScribeNick: harris Found Date: 09 Jan 2020 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]