<jamesn> https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2018#May_1_-_Agenda
<MichaelC> scribe: MichaelC
jd: We´ve been asked to do role parity to support web components
mk: what´s the issue?
jd: web components mix markup and script to create features, e.g., a list
dm: or paragraph, which currently doesn´t have ARIA version
jd: having an ARIA role allows it to be treated like the corresponding HTML feature
dm: web component authors want custom components for everything
even basics like select, paragraph, etc.
have it behave like the HTML version but with custom behaviours
the host element´s tag name can´t be set to something meaningful, if it´s different from the native element, if there isn´t ARIA feature
there can be reasons to use a different element than the one you´re representing
mk: is the shadow dom exposed to a11y tree?
as: can access it but need to decide what to expose
<joanie> https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements
dm: can extend a HTML element
<joanie> customElements.define('word-count', WordCount, { extends: 'p' });
but there are times when you can´t or don´t want to
so instead of trying to anticipate every workaround, role parity allows authors to not have to worry about it
jd: another reason, HTML AAM maps some HTML elements to ARIA roles
which allows avoiding separate mappings for that feature, defers to Core-AAM in those cases
means AAPIs don´t need to know / care whether the feature was HTML or ARIA
extending this to the rest of HTML allows more easy maintenance of HTML AAM, just need ARIA mappings not AAPI mappings
we don´t own some AAMs
(SVG and HTML)
mk: would we need HTML AAM then?
jd: yes but it would just map to ARIA
dm: maybe combine documents in that case
jd: tangent alert!
dm: AOM also needs role parity
AOM creates virtual objects
unlike custom elements, they inherit nothing from HTML
so all the more so, need to be able to provide roles for things like paragraphs
jd: generic vs specific - do we need a paragraph role, or a more generic text block role?
e.g., <pre> and <code> could maybe share same mapping
maybe nothing wrong with that
gg: could lose semantic info in that case
jd: but in some cases, it might not be important enough to distinguish
mk: don´t want properties to be the reason we have two different roles
e.g., aria-haspopup can change role mapping, causes lots of confusion
if there were a text role combining pre and code distinguished by properties, would be a mess
<joanie> https://github.com/w3c/aria/pull/718
mc: let´s agenda+ that along with taxonomy discussion
jd: ^ has some elements that I think need specific roles
my platform has specific features for each of those
otoh might be able to combine caption and figcaption
mc: unsure about that
<quick kerfuffle of semantics>
<joanie> https://rawgit.com/w3c/aria/text-block-roles/#paragraph
<joanie> https://rawgit.com/w3c/aria/text-block-roles/#header
<joanie> https://rawgit.com/w3c/aria/text-block-roles/#footer
<joanie> https://rawgit.com/w3c/aria/text-block-roles/#blockquote
<joanie> https://rawgit.com/w3c/aria/text-block-roles/#caption
<quick digression on pr-preview tool>
jd: for caption, always set describedby on elements it´s describing
mk: it´s a child node
jd: for table, but not always figure
gg: does caption replace name?
jd: no
mk: aria-describeby does not require role
mc: caption and name is an AccName question, let´s defer there
<dmazzoni> My brainstorming list of ARIA / HTML gaps:
jn: reversing describedby, it´s more a describes
mk: name and value often get combined in naming algorithm
for paragraph, is its entire content its name?
gg: no, you´d walk text content if you wanted
what we´re discussing is name *if provided*
jd: remember the ¨name from¨ in the spec says where the name should come from
mk: I´ve wondered if we need a way to say something is not nameable
theroom: +1!
jn: agenda+ing that
dm: @@
gg: ambiguity in name for different elements, and different people have different views
jd: we try to address that with the namefrom options in the spec
gg: issue for screen readers is not reading top to bottom, but when element gets focused, what should be read then?
mc: when reading top to bottom don´t read names, but when fousing you do?
gg: kinda, in augmentative mode you might even top to bottom, but there´s more context
mk: so caption is for ¨another element on the page¨, is that too broad
gg: just saying a caption is a caption is too broad
jd: @@defending
dm: isn´t caption and label somewhat ambiguous
jd: labels short
though captions can be
dm: let´s not use length as a distinction
would rather say semantically caption is a special type of label
jn: avoid term ¨label¨ also
mc: +1 to not using term to define itself, dictionary helps, and can use to disambiguate from other terms we use
<some wordsmithing>
mc: let´s come back to editorial style guide wrt how to define roles later
dm: a generic definition for caption but distinguish from form labels
mk: need to consider APG, I have to be able to describe specifically how to use it
can we have captions for other things like videos, lists?
mc: argument in favor of generality, web components authors might indeed want to do that?
<Zakim> joanie, you wanted to propose an alternative
jd: @@
jn: HTML spec also favours combining the caption roles
<joanie> >On-screen descriptive text for a figure or table in the page.
mk: about footer, I understood it @@, but it´s a landmark
jd: HTML AAM has 2 conditions, one scoped to main, one scoped to section
mk: sometimes it maps to contentinfo, so identical
if we create role footer, ARIA spec would have to incorporate those
mc: but you don´t want roles to be changeable from context
jd: HTML AAM says there are 2 footers, one maps to footer and one maps to contentinfo
mc: so we just need a footer role, but not to give contextual mappings
HTML AAM does that if it wants
mk: same for banner and header
<...>
gg: it´s a weird mapping but stuck with it in the wild
jn: the word ¨banner¨ often used for headers
jd: should we deprecate banner?
jn: yeah, how about ¨footer¨ and ¨header¨
will agenda+ on that
jd: do we need to disambiguate contentinfo, or introduce header and footer, and deprecate contentinfo and banner
mc: not the latter
mk: if landmark, @@
jd: last low hanging fruit, blockquote
mc: but there´s blockquote and q, do we want to distinguish?
<rathole on whether q is a style or semantic element>
dm: generic quote element with a property to clarify role could work
mc: +1
mk: prefer to keep separate, blockquote treated differently by AT
so having a combined role is one more things for authors to get wrong
dm: so simplest thing for authors is to have 1:1 parity between HTML elements and roles?
mk, gg: and they can be nested, etc.
dm: but that´s not universal to web design
mc: can we accept quote mapping to blockquote, and come back to q?
jd, mk: no, really want blockquote now
and not quote which might mix things up
dm: inline vs block exposed in DOM
gg: we use that?
dm: inline div different from block div
mc: let´s accept blockquote now, knowing we might modify the decision when we discuss q
jd: though I won´t accept quote role ;)
<bgaraventa1979> comp is acting wiggy, will log back into IRC after restart, still on the phone though
<jamesn> https://github.com/w3c/aria/issues/525#issuecomment-385649311
jd: we have inline vs block
sections also seem pretty generic
could make section non-abstract and use as an ancestor for other generic roles
jd: section feels larger
mk: would map to div
mc: HTML section is less generic
could be confusion
jd: <reads from HTML section, notes how tongue twisting it is>
isn´t that the essence of a generic role?
scribe:
dm: I´ve seen code that references a div with ID, which means we have to decide what to do with divs
at some point any element could need to be exposed
jn: @@
mk: I´ve seen div get turned into role by other things used on it
what would mapping be for section role?
jd: maps to landmark w/o name, and region w/ name
<jamesn> region role if the section element has an accessible name. Otherwise, no corresponding role.
<sorting all that out>
mk: what about div?
jd: no role, but similar mappings
if something is mapped, not forced into a11y tree
AAM says ¨if you expose it, here´s how¨ not ¨you must expose it¨
mk: so if section becomes concrete, would work in parallel with those
how does it compare to span?
jn: same or not mapped depending on platform
jd: normally not mapped
mk: so spans disappear into parent if have no role
jd: text formatting exposed on some platforms via accessible text interface
mc: so will we later want to map HTML section?
various: effectively, no
mk: so no rendered difference
jd: moving on to text...
mc: uh-uh, let´s close one topic before moving on to next
<leading to more circling around generic containers>
dm: sometimes you just wanna group stuff
w/o other semantic implications
gg: nomenclature, sections mean something e.g., in books
mk: we´re essentially saying div now has a corresponding role
the main use case is we need to distinguish between default block semantics and default inline semantics on generic containers
right now it´s heuristic
jd: people are commenting, do we want to consider unabstracting structure instead?
various: no
<dmazzoni> Scribe: dmazzoni
(Discussion about the current role taxonomy and where section, region, etc. are)
JN: I don't like un-abstracting "section", I'd rather have something new
JD: We agree that there should be a generic block and inline?
How about role=div and role=span?
AS, GG: How about role=block and role=inline?
MK: we should have something like aria-inline to allow any element to be treated as block vs inline
or aria-display="block"/"inline"
<joanie> https://github.com/w3c/aria/issues/525#issuecomment-385649311
JG put those in the straw poll
DM: Note that we need generic block and inline elements, and something like aria-display, for AOM
MK: HTML-AAM has a section on whether certain nodes must be included in the tree; we may need to update that part of the spec
<jamesn> https://www.w3.org/TR/core-aam-1.1/#roleMappingGeneralRules
(Correction: CORE-AAM, not HTML-AAM) - see link above
Possible rough consensus on role=block, role=inline
AS: What about other display values, like flex, flow, etc.?
AS would prefer a generic role
rough consensus is for role=block, role=inline, with aria-display="block"/"inline" in 1.3
<joanie> https://github.com/w3c/aria/issues/525#issuecomment-385698322
<joanie> https://github.com/w3c/aria/projects/3
<bgaraventa1979> the audio on your end is still muted
<joanie> https://github.com/w3c/aria/issues/697
Melanie Richards joined and introduced herself
JN: We want to go through a bunch of roles and decide if we want a specific role, generic role, or needs more discussion
See the issue above
JN: These are roles that all have mappings in HTML-AAM
The decisions won't be scribed, check the issue
MK: Does address really need a role?
JD: Everything we're discussing now does have a mapping
DM: I think if we have at least one mapping we should add a role
Canvas will be discussed further later
Discussing DL - unclear because OL and UL map to list
EMBED/OBJECT - defer, do we need them?
<melanierichards> confirming that we (MS Edge) have fieldset mapped as group
(Discussion continuing, we're on RUBY)
<joanie> https://github.com/w3c/aria/issues/698
Now we're considering ones where they're mapped to something other than an ARIA role
The discussion for B, I, EM, STRONG, U, and others in that family is that those should be mapped to a generic inline role
possibly with ARIA attributes to indicate the styling
<joanie> melanierichards: colgroup is mapped on your platform. Why? :)
<melanierichards> will have to add that to the investigation list too!
<joanie> please do. :)
Discussion about col and colgroup, we're leaning towards not mapping them at all
Discussing whether SUP and SUB are different than B, I, EM, etc
On to the next list:
https://github.com/w3c/aria/issues/696
DL will get a specific role, the question is if we need something specific for DD and DT other than what we have now?
and DFN
<joanie> https://www.w3.org/TR/html/textlevel-semantics.html#the-dfn-element
Discussing different elements inside of the html <menu> tag, not the same as role=menu
<david-macdonald> https://html.spec.whatwg.org/multipage/grouping-content.html#the-menu-element
Looks like role=group should be allowed in a listbox, I'm filing a bug
https://github.com/w3c/aria/issues/719
<bgaraventa1979> +q
<david-macdonald> https://www.w3.org/TR/wai-aria-1.1/#aria-valuetext
JD: proposing a "root" role for svg root
<bgaraventa1979> signing off, will be back tomorrow.
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/ja:/dm:/g Succeeded: s/caption/mc: caption/ Succeeded: s/latteer/latter/ Succeeded: s/now/how/ Succeeded: s/as well/instead/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Present: bryan_garaventa Matt_King Glen_Gordon James_Nurthen Michael_Cooper Jon_Avila Alex_Surkov Joanmarie_Diggs david-macdonald Found Scribe: MichaelC Inferring ScribeNick: MichaelC Found Scribe: dmazzoni Inferring ScribeNick: dmazzoni Scribes: MichaelC, dmazzoni ScribeNicks: MichaelC, dmazzoni Agenda: https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2018 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]