[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

W3C

ARIA FtF Day 1

02 May 2018

Agenda

Attendees

Present
bryan_garaventa, Matt_King, Glen_Gordon, James_Nurthen, Michael_Cooper, Jon_Avila, Alex_Surkov, Joanmarie_Diggs, david-macdonald
Regrets
Chair
Joanie_and_James
Scribe
MichaelC, dmazzoni

Contents


<jamesn> https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2018#May_1_-_Agenda

<MichaelC> scribe: MichaelC

Role Parity

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:

<dmazzoni> https://docs.google.com/spreadsheets/d/e/2PACX-1vSp4pQyMX1ShgRJZD6keUK_XRuqD39yGl1YgjskwDsCK2pY0TcMPm7g1ONwC1nFXEu7AGTgLfSPvsHm/pubhtml

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

Generic vs specific roles

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.

Summary of Action Items

Summary of Resolutions

    [End of minutes]

    Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
    $Date: 2017/02/06 11:04:15 $

    Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
    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]