<scribe> scribe: pkra
jamesn: issue 1033
... I'll propose 1.2
... issue 1032
... any comments?
<jamesn> https://github.com/w3c/aria/issues/1032
scott: related to aria-expanded.
jamesn: yes, split off from
there.
... does this clarification need to happen 1.2?
matt: it's ambiguous.
... we talked about the case of multiple tabs and indicating
other things.
... creates cognitive dissonance.
<Jemma> no
jamesn: let's put it in 1.3
<Jemma> no objection
<jamesn> https://github.com/w3c/core-aam/issues/52
jamesn: posinset calculation
joanie: hasn't yet been
migrated.
... nothing to do with specific platforms.
... was this related to mozilla menu separator?
jamesn: yes.
joanie: I suggest 1.2, part of
the migration of content.
... but also a candidate for F2F
worth getting many stakeholders in a room and deciding when a UA has to calculate, what should they.
Matt: is making this normative requirement part of this?
jamesn: not right now but could
be.
... especially at F2F
matt: I could raise a separate issue but if not necessary then I won't.
joanie: re group position, I think we want this normative.
matt: says something like "browser can do this", not SHOULD, MUST, or MAY
jamesn: it's a MUST in core-aam.
matt: great. then no issue and we can file bugs.
jamesn: let's be careful since
this might break a lot of things
... aria#1031, put in 1.2
jamens: aria#1030 we'll discuss later and possibly TPAC
jamens: new PR from harris.
<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/1029.html
jamens: we had decided on
removing aria-level from grid but hadn't decided on tabs
yet
... we can put it for review for next week
... let's mark it as non-draft and review next week
<jamesn> https://github.com/w3c/aria/issues/1001
jamesn: I haven't got around
doing a real agenda yet.
... I'll work on coordinating with other groups later
today.
... if you have more topics, put them on.
... and link to related issues
matt: I've worked on the combobox
issue. not yet worked out how to structure that.
... 90mins is a long time. Everytime we discuss it, there are a
lot of different angles on it.
... might be divided into discussion of related "normal
comboboxes" (textinput), another one around HTML-aam#46
jamesn: will you lead the discussion?
matt: yes, I plan to prepare presentations.
<harris> "native" combobox: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist
<jamesn> https://w3c.github.io/annotation-aria/
jamesn: it's still early stages
but we have something to discuss and comment on by the
group.
... allows things for commenting, e.g., google docs,
office365.
matt: is this becoming a module rather than part of ARIA?
jamesn: yes, that's the plan
right now.
... didn't want to take up the whole group. Good to have it in
one place.
joanie: in a way, it's like dpub
and graphics-aam.
... we want all UA to add support for all of our specs.
... nevertheless, separating things out prevents UA from being
considered incomplete - for better and worse.
matt: work out potential conflicts between module and main spec, e.g., with dpub.
jamesn: annotation starts with aria-details plus additional roles. Less of a dependency, though dpub is actually another dependency.
matt: the vision of AT for aria-details is still unclear to me.
jamesn: if that helps clearing up
aria-details, that's definitely good. Google's interest means
we should see it in Chromium.
... please comment.
joanie: of course we'll eventually need a corresponding AAM.
jamesn: yes. for now, keep it in one document for simpler review.
jamesn: has come up in several discussions recently
<jamesn> https://github.com/w3c/aria/issues/748
<jamesn> https://github.com/w3c/aria/issues/1030
<jamesn> https://github.com/w3c/dpub-aria/issues/15
jamesn: basic question is: what does "owned" mean.
<Scott_O> https://www.w3.org/TR/wai-aria-1.1/#aria-owns
<Jemma> "aria-owns Identifies an element (or elements) in order to define a visual, functional, or contextual parent/child relationship between DOM elements where the DOM hierarchy cannot be used to represent the relationship. See related aria-controls.
https://w3c.github.io/aria/#mustContain
?
<jamesn> An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child.
scribe: this would mean any child or descendant or referenced by aria-owns are owned.
<joanie> https://w3c.github.io/aria/#terms
scribe: but I believe for
platforms that they don't actually implement it that way.
... e.g., list. If list items are nested 7 levels deep, they
wouldn't come out as owned elements, posinset wouldn't work
etc.
matt: what happens in HTML if you have a ul and then a bunch of tags before the firs LI
scott: it mucks up the tree. Might expose it as no list items, as separate lists - it just breaks.
matt: in practice, we see divs
that are just containers for styling, scripting etc.
... if they had content (e.g., text, spans with text), that
would be different.
<jamesn> https://github.com/w3c/aria/issues/748#issuecomment-473594928
joanie: as screenreader dev, we see also sorts of garbage in the tree and have to cope with it.
jamesn: my first thought was to restrict to direct children etc (see #748)
matt: what is the problem we're trying to solve? just posinset?
scott: seems odd to look for
parity with HTML but allow for things that you cannot do in
HTML.
... you cannot have li surrounded by divs
... so we shouldn't have it with ARIA
matt: what does it mean "you
can't do it", what's the consequence in practice?
... I see e.g., tables with lots of tr > div > div
>... > td..
scott: right, but it breaks how things are exposed.
Bryan: they work for a different
structural type.
... spec never says you have to put role=none/presentation
etc.
... but it will actually break it.
matt: so it's like a select to put a div around options.
Bryan: Right. I'm just saying that the spec doesn't say and there's a lot of content like it and if we change the spec, it will break that content out there.
jamesn: we look at different things. If you override the parent role, then the child role must change. But then you might have tables with role=grid and tr's are still ok.
matt: but those map correctly.
jamesn: right but this is a lot to work out. THis is rapidly becoming a F2F topic.
matt: it doesn't work independently of accessibility.
scott: list example: if you wrap
li's in divs, it will have inconsistent representation across
AT.
... of course it's not valid HTML
bryan: maybe it should be put in the spec on each role. But if you make it global, then we are going to screw things up somewhere.
joanie: it's likely that at least on one UA is going to push back on a new requirement to check.
jamesn: there are already things that we expect them to fix.
joanie: and they also don't necessarily fix those...
jamesn: second part: we have
several places where we have text saying one thing but required
roles say another.
... listitem role: is in list or directory but directory not in
required context role.
... so we're missing one or the other.
... other cases of inconsistencies.
matt: let's ignore combobox for
now - it's a different rabbit hole.
... but listitem seems like a simple bug.
... though I haven't come across directory a lot in real
life.
jamesn: should we obsolete directory?
matt: yes.
<Jemma> https://w3c.github.io/aria/#directory
matt: does dpub have a dependency?
pkra: doc-toc has superclass navigation but example has then child OL with directory :
matt: I'm not aware of UA doing anything with directory.
<BGaraventa> isn't there a code search utility for finding public usages of role="directory"?
<Jemma> "Authors SHOULD use this role[directory] for a static table of contents, whether linked or unlinked. This includes tables of contents built with lists, including nested lists. Dynamic tables of contents, however, might use a tree role instead.
jamesn: would be good to go through all required context roles and make sure they match the prose.
matt: 1 issue or many?
jamesn: whoever tackles it.
matt: should mean that deprecation has no effect.
jamesn: we should check if dpub et al use it for something else.
<BGaraventa> I recommending doing a code search to see if public sites are already using this first
<jamesn> https://github.com/w3c/dpub-aria/issues/15
jamesn: the dpub issue is a bit
thorny
... doc-biblioentry can't be used as child of a list right
now.
... we have no way to specify that it's a required owned
element.
<joanie> Authors MUST ensure that elements with role doc-biblioentry are contained in, or owned, by an element with the role list.
jamesn: and we specifically say that it doesn't inherit this way.
<Jemma> "doc-biblioentry (role)ยง A single reference to an external source in a bibliography. A biblioentry typically provides more detailed information than its reference(s) in the content (e.g., full title, author(s), publisher, publication date, etc.). Authors MUST ensure that elements with role doc-biblioentry are contained in, or owned, by an element with the role list."
jamesn: we do this because we have things that subclass from several things
matt: overloading.
... DPUB would need a biblio role and have the mapping just
like a list etc.
... I don't understand why they needed this.
<harris> I've gotta drop off. Cheers everybody!
joanie: we can accomplish something similiar to macOS subroles in IA2 and ATK to figure it out via the xml-roles object attribute.
matt: if dpub-aam mapped
biblioentry and biblio correctly, then they could just define
their semantics inside the dpub spec
... with no dependency to aria for this to work.
jamesn: so they have to not use any aria roles in their spec?
joanie: we should fix our
spec.
... the solution shouldn't be that every module has to do all
this work just because our definition is broken.
jamesn: I agree. We should fix our definition to allow this kind of extension.
<Jemma> https://www.w3.org/TR/dpub-aria-1.0/#doc-bibliography
pkra: there's also doc-bibliography but it's a landmark.
matt: seems similar to recent discussion around feed.
aaron: a lot of dpub stuff is useful for braille embossing, lots of custom braille notations for it.
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/???/Bryan/ Succeeded: s/jamens/jamesn/ Succeeded: s/XMLrole/the xml-roles object attribute/ Succeeded: s/connect our specs/fix our spec/ Succeeded: s/we can accomplish something similar for Orca/we can accomplish something similiar to macOS subroles in IA2 and ATK/ Default Present: Joanmarie_Diggs, pkra, Scott_O, MichaelC, jamesn, harris, Bryan_Garaventa, Jemma, Matt_King Present: Joanmarie_Diggs pkra Scott_O MichaelC jamesn harris Bryan_Garaventa Jemma Matt_King Regrets: CurtBellew Found Scribe: pkra Inferring ScribeNick: pkra Found Date: 15 Aug 2019 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]