<scribe> scribe: carmacleod
<jamesn> https://github.com/w3c/accname/issues/81
survey for additional meeting time either before or after this call
<Jemma> https://www.w3.org/2002/09/wbs/83726/meetingTimes/
jamesn: still open - please give your answers
jamesn: want to merge this
shortly - broken out into aria and aria-common - if anyone has
any last minute changes, let me know
... will be merged in the next day or two, will push to master
as well
<jamesn> https://github.com/w3c/aria/pull/1224
mck: this is on my priority list to review
<harris> does it show up here? https://github.com/pulls/review-requested
<jamesn> https://github.com/w3c/aria/issues/1150
jamesn: what do we really mean by
"descendant"? There are 96 instances in the spec.
... do not (usually?) mean "direct descendant" or "child" -
usually mean "any descendant"
... we are not really clear in all cases whether we allow
intermediary descendants
jcraig: the OP mentions that we changed from DOM3 to DOM4
<jamesn> https://www.w3.org/TR/wai-aria-1.1/#informative-references
jamesn: ARIA 1.1 references DOM -
the living standard (which is "DOM4")
... moving this issue to ARIA 1.3
<jamesn> https://github.com/w3c/aria/issues/1058
<jamesn> https://github.com/w3c/aria/issues/978
<jamesn> https://github.com/w3c/aria/issues/834
jamesc: both of the IDL issues assigned to me I moved to 1.3
<jcraig> https://github.com/w3c/aria/issues/1058#issuecomment-548544675
jcraig: I will assign the other
one #978 to myself as well
... Domenic D's comment gives a line of prose that seems
good
... in #1058
<jcraig> Dominic's comment: At a quick look, it seems like a reasonable fix here would be some glue at the top of the ARIA spec, which says something like "when we have a table enumerating the values for an attribute, then that attribute is an enumerated attribute. When we notate one of the values as (default), then that value is the missing value default and invalid value default for the attribute."
jamesn: looking at #978 - in the 1.2 current working draft, these are just strings - we need to change that for 1.2
jcraig: agree this needs to be done for 1.2
jamesn: is 978 the way to solve 834?
jcraig: maybe, but maybe for 1.2, just remove them for 834. want to wait for element reflection to be finalized first.
jamesn: I'm ok with that - joanie?
joanie: sure
jamesn: I will assign 834 to myself
jcraig: ok, will mention that in 978 - we are removing 834 for 1.2
mck: so we should be ready for CR in the next couple of weeks?
jamesn: depends on if joanie is ok for core-aam
joanie: should be good to go
<jamesn> All of the ways aria-hidden is misunderstood and misused, and what can be done about it?
<jamesn> - People using aria-hidden=false, thinking it gets undone
<jamesn> - aria-hidden on the <html> or <body>
<jamesn> - aria-hidden on content that is visible and tabbable, or aria-hidden on something that actually gets focused
jamesn: aleventhal, please introduce the aria-hidden-pocalypse
aaronlev: can't blame authors for getting aria-hidden wrong because it'
s confusing
aaronlev: people put it on the
root element or body element
... people think that aria-hidden="false" undoes it
... try to define a set of rules where aria-hidden is used
illegally, i.e. if on body, browser should disallow
... if aria-hidden="false" on subtree, let browser have it in
a11y tree
jcraig: only if subtree is rendered
<jcraig> 1. aria-hidden on root element on entire page contents
<jcraig> 2. aria-hidden on elements that are currently focused
<jcraig> 3. aria-hidden=false on visible elements inside some ancestor with aria-hidden=true
<jcraig> 4. defined API for "marked as hidden, but still in the accessibility tree
<jcraig> my opinion is that #4 is the most controversial. The rest seem reasonable
<Jemma> https://github.com/w3c/aria/issues/1190
aaronlev: I see 4 areas: aria-hidden on roots, on focusable things or things that get focus, on things that are rendered subtrees marked false, on platforms where the API allows authors to say what is hidden
<jcraig> I think exposing focused elements in #2 negates the need for #4 (I may be missing a use case though)
sina: let the screen reader decide
<Zakim> jcraig, you wanted to say I think exposing focused elements in #2 negates the need for #4 (I may be missing a use case though) and to disagree with Sina that AT should not need to
jcraig: disagree, because it is a lot of logic to add to every AT
<joanie> +1 to James' statement that it's up to the user agents and not the ATs.
jcraig: it is the business of the user agent to decide what is an authoring error
sina: I mean in the explicit case where there is an authoring error - the screen reader can do remediation
<Jemma> https://github.com/w3c/aria-practices/issues/258
jcraig: I think aaron's idea that we spec what are the authoring errors are, and that lets the user agents figure out what to expose
sina: unintentional presence or absence of content is really frustrating for a screen reader user
jcraig: aaron's solution will probably expose more content
jamesn: agree that we should look at the places where people get this wrong and spec them out
jcraig: for point 2 above, I said "aria-hidden on elements that are currently focused" where "focused" is important (not "focusable")
<Jemma> https://github.com/w3c/aria-practices/pull/1045
aaronlev: we do "focusable" in Chrome
<Jemma> +q
<Zakim> jamesn, you wanted to respond to jcraig
mck: at the high level, I'm
really on board with the 4 points
... since we are only talking about making content that would
have been unavailable to the screen reader available
<BGaraventa> +q
mck: this can be bad, but it's never as bad as the other direction (making content that is supposed to be available unavailable)
<pkra> gotta run. bye.
<Zakim> jcraig, you wanted to say I agree the user needs context on the focused element (such as label) but exposing everything around it (like heading) seems extreme and potentially
bryan: I think this discussion is important, and I see it a lot, particularly aria-hidden="false" on a dialog, but we need to discuss recursion, i.e. aria-hidden="true" on something in the dialog
jcraig: I don't see that being a
problem, we can address recursion in the user agent
... focused: land on an element, it's aria-hidden, where am
I
<Jemma> Jemma: I peppered related APG link and issues to the IRC. I wonder what we can do at ARIA APG, adding more contextual information about using aria-hidden?
jcraig: there might be other form elements around it that have valid aria-hidden=true - need to solve that
aaronlev: I don't have a problem exposing too much content - this is an authoring error
bryan: web page with aria-hidden true, dialog with aria-hidden false, and you swipe on ios, then will not fire focus, so will never be focused
jcraig: there are some scenarios where we do expose aria-hidden=false, but they are complicated
sina: scenario: aria-hidden=true
on body and aria-hidden=false on an input
... and I swipe on touch screen
jcraig: that's point 3 of the 4 -
aria-hidden=false on visible elements inside some ancestor with
aria-hidden=true
... I think we can do something about that
<Zakim> jcraig, you wanted to reference inert
mck: we need to make it more difficult, and maybe even illegal to hide rendered content
sina: can't do that because carousel authors may need to render stuff offscreen to make their animations work
jcraig: inert
... tabindex=-1 is "click focusable" not "tab focusable"
... with inert, which is coming soon, events - including focus,
click, key... - are suppresed
... so ideally, should map inert to aria-hidden, which will
prevent focus, many of these problems will magically go away
with inert
... so we shouldn't go overboard undoing aria-hidden now,
because inert will solve most of these problems
mck: rather than just making it
harder for authors to hide stuff using aria-hidden, but the
rules have to be super clear
... if "I'm going to show this to people who can see the
screen, but not to people who are using a screen reader", then
need rules for when to use
... if an element receives focus, aria-hidden=true is invalid,
page gets exposed, then tab away - content is still
rendered
jcraig: if focus event, and element was aria-hidden=true, then remove aria-hidden from that element
sina: so developer will see it disappear in devtools - agree completely
bryan: scan upward to the nearest aria-hidden and remove that
sina: if it's on a dialog and you focus the dialog, then remove aria-hidden from the dialog
<jamesn> /me I have to leave
jcraig: aria-hidden can be on multiple elements so can walk up the tree and remove from all ancestors
aaronlev: should I just add it to a map, or really remove it?
jcraig: if you add it to a map, the author will be really confused
aaronlev: can warn in the console log
mck: if aria-hidden on a dialog, and a focus change event is triggered within the dialog, then that's the only time we would remove aria-hidden
aaronlev: I like making
aria-hidden="false" a viable thing to do, but I think it will
break some implementations - just want to point out that others
may disagree
... accessibility focus event
jcraig: should probably
differentiate between iframe and shadow dom as well
... I will take the action to open issues for the 2 clear
cases
... focused aria-hidden, and aria-hidden on large areas of
content (body, etc)
... the last one I file will be aria-hidden=false within
aria-hidden=true region, and I will loop Alex S and James Teh
in on that one
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/reflectioin/reflection/ Present: Joanmarie_Diggs harris Jemma jamesn carmacleod Matt_King StefanSchnabel BGaraventa pkra CurtBellew jongund aaronlev sina Found Scribe: carmacleod Inferring ScribeNick: carmacleod 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: 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]