Accessible Rich Internet Applications Working Group Teleconference -- 14 Feb 2019

<pkra> \o/

<aaronlev> jamesn: I'm lurking on IRC in case bigbluehat is around to plan annotations meeting

<scribe> scribe: MarkMcCarthy

New Issue Triage

<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-02-07+

jamesn: 4 new issues, we probably triaged most already
... 901 put in 1.2 bucket

joanie: not at this meeting, but I threw out an option that we can discuss on the issue. I'd like some feedback if we want to limit caption in the case of table

jamesn: let's try to put on agenda for next week

joanie: awesome

<joanie> https://github.com/w3c/aria/issues/901

jamesn: change W3C editorial version to whatWG
... HTML validator no longer reflects W3C version, all W3C code removed from validator. suggests we want to point to other version
... comments? 1.2 bucket?

carmcleod: why did they take that out?

jamesn: I don't really know the story behind it
... I only know hearsay

carmacleod: okay

<pkra> This might be relevant: https://www.w3.org/blog/2019/02/w3c-strategic-highlights-strengthening-the-core-of-the-web-html/

jamesn: we can reference W3C living standards, so there's no restriction there

carmacleod: I wonder if... if the W3C is publishing snapshots, it makes sense to reference.

jamesn: I've just logged an issue, I don't think we need to solve it now, just before we publish 1.2
... just so we don't forget it. so 1.2 bucket?

carmacleod: okay

jamesn: I'll add that it needs discussion before implementing
... address issue 899 later today
... issue 888 can go in 1.2 bucket.
... melanierichards is taking care of that

melanierichards: whenever we end up doing attribute parity, if it's 1.2 or 1.3...

jamesn: right! it's 1.3.
... no new issues with ACCNAME or COREAAM

F2F Updates

jamesn: MichaelC has set up a meeting page

<jamesn> https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2019

jamesn: with more details. confirmed April 30-May 2, in SF hosted by LevelAccess
... topic is to nail down as much role parity as possible.

joanie: quick question: is SF airport the closer one?

jamesn: SF airport is easiest, but Oakland has BART as well. Uber is better with SF

need role for sub and sup

<jamesn> https://github.com/w3c/aria/issues/877

jamesn: joanie, do you want to put up some details?

<jamesn> github: https://github.com/w3c/aria/issues/877

Sub and Sup

<jamesn> github: https://github.com/w3c/aria/issues/877

joanie: sup and sup were originally identified as needing their own roles, leaning towards that
... mck suggested maybe we could use the generic role
... what I put, before carmacleod commented, are thoughts on why we want a role, in particular if there's semantic meaning

<joanie> These elements must be used only to mark up typographical conventions with specific meanings, not for typographical presentation for presentation’s sake. For example, it would be inappropriate for the `sub` and `sup` elements to be used in the name of the LaTeX document preparation system. In general, authors should use these elements only if the _absence_ of those elements would change the meaning of the

<joanie> content.

<pkra> pfffft

carmacleod: Sure. It'd be interesting to have an attribute on that new role as well, as you've opened the other bug.
... I was thinking if we put it as a generic, there's an option to have another attribute as well as context
... I called it aria-typography, but that's completely a draft name
... reason being, the other genric roles we've talked about, all those almost fit in the same area. I just want to look at the bigger picture first
... these are sort of the same idea? if we throw thwem all into the same attribute that specifies "presentational semantics" maybe that's good enough?

joanie: I raised the point I did since I am a screen reader developer
... and the generic role might be everywhere. for sup/sup, we might want to announce them differently than the others
... what carmacleod is describing is essentially asking to check every generic role for what it's content is
... what might be funny with mapping is that the way it might be exposed might be different
... aria-typography might be better for something like CSS

carmacleod: I didn't know your platform has it in the API

<Zakim> joanie, you wanted to disagree

mck: as long as I can remember, we've had this discussion role vs. property
... there's a whole lot of HTML that by default does some styling to communicate a semantic, like bold vs. strong, headings, etc.
... these individual decisions about aria-attribute vs. role seems like a discussion where we don't have many principles, except what joanie mentioned about platforms
... we don't have consistency across the board with accessibility APIs
... if anyone can come to the table with cohesive principles, that'd be hepful. I don't see it.

pkra: the spec description for sup/sup seems weird. wisest choice might be to say do what HTML does
... doesn't seem wise to go beyond what they're giving, esp as this is parity

<Zakim> joanie, you wanted to say the principle is that if an AT can ignore it and the user experience doesn't change, it's generic

joanie: if an AT can ignore and UX doesn't change, it's generic
... user needs to know about headings, for instance. for sup/sup, X2 vs X sub 2 or X sup 2 is different

mck: if reading a text, and you say "all boldface text means XYZ," then there's meaning with bold text that screen readers don't know
... reader may want to choose to have bold read differently
... could argue this is true about headings as well

<joanie> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/strong

<Zakim> joanie, you wanted to say strong versus bold elements

mck: we might want to mimic HTML, which might not be best but defendable

joanie: I hear you mck, but HTML for better or worse has bold and strong. sometimes authors need guidance
... authors should use b tag if it's not semantically important, strong if it is
... so I'd like b to be generic, ideally, and strong not generic, so screen readers present items differently

mck: do DPUB folks have something to say?

jamesn: no one here today

pkra: I don't know why use case isn't mentioned, but there's obvious use of subscript, like chemistry etc.

jamesn: we'll have annotations

pkra: though I suppose you find footnote -scripts in MathML too

jamesn: are we near a conclusion? many opinions. I'm leaning towards that if it's on a platform API then go for it

carmacleod: +1

joanie: yes, but not all APIs have the same things

jamesn: it should be an indicator to us that if it's in a platform API and we decide it's not semantic, that'd be a mistake

mck: what we don't tell screen reader devs is that you always announce roles and sometimes properties - that's not our job

joanie: right, i didn't say that
... concensus is what?

jamesn: expose as roles?

carmacleod: yes, i'm okay with that. I can see the screen readers POV now

<pkra> +1 for roles

mck: maybe for the generic case, it's generally the browser's responsibility to take care of element attributes?

jamesn: let's talk about that when we come back to generic

mck: let's go forward with roles

[no disagreements]

JamesCraig: thanks for discussing generic, it's important to me

Issue 867: add draft specification for role label

Role Label

jamesn: this is jongund's PR, there's been some updates

<jamesn> github: https://github.com/w3c/aria/issues/867

jongund: updates are that I added the roles we discussed, I'll add a link to changes

jamesn: 867 is the wrong issue, oops!

oops

<jongund> https://raw.githack.com/jongund/aria/issue876-role-label/index.html#label

jongund: this should be updated code. I went through roles related to encapsulation based on HTML5

<jamesn> github: https://github.com/w3c/aria/issues/876

jongund: I changed the language a little bit, but the big issue is defining what the list of roles would be and how to get an acc name to them
... there's 30-40 different roles, take a look

mck: i still think there needs to be a way to represent this for tables, something equivalent like encapsulation
... especially with all the tools that parse our spec

jongund: i agree
... there should be something in the table for roles that can be labelled through encapsulation

jamesn: this is way more than I expected based on last time

jongund: i thought it'd be a small list too, but then you have to look at the principles and what HTML does

jamesn: things like a document or an alert...

mck: or buttons, maybe there are some things to throw out

jongund: I'm happy to take some things out if necessary

mck: anything that's a structure has to fall out of here

jamesn: some things should have further discussion, but let's start with a smaller list first and add more later
... a small list going into production first would be better

mck: is an aria-button like an input type or element? semantically it's equivalent to both?

carmacleod: yeah, it's weird

jamesn: let's take out button and add it back if we want to

mck: combobox is weird, since it's complex

carmacleod: but it needs a label

jongund: the question here is what makes sense from an authoring standpoint

<carmacleod> List of labelable elements in html: http://w3c.github.io/html/sec-forms.html#labelable-element

jongund: one of the things this does is let people have a visible label. so it's probably more useful for combobox than checkbox
... I don't have to worry about IDs, or aria-labels or -labelledby

jamesn: I'm happy to hear either way on combobox
... let's go through a smaller list next week?

JamesCraig: I think it's fine for any form control, but if we decide to keep structures it's possible to have some implementer impact

jamesn: that sounds like a good comment. I'd like to limit to form elements and add other useful things later

<CurtBellew> I'd like to understand why "list" wouldn't be on this list

jongund: i'll whittle down the list and we can discuss next week

CurtBellew: I can wait til next week. I've had a question on that for a while but happy to wait

JamesCraig: one more thing, where would encapsulation stop?
... that's something we need to consider
... i.e. can i walk up the ancsestor chain, do i encounter anything that'd conflict?

jongund: that'd be in ACCNAME I think
... but you're right, that has to be defined

ARIA Spec could be more flexible when elements with “nameFrom:author” are left unlabeled by the author

Flexibility of namefrom

jamesn: this is what JamesCraig wanted to discuss

<jamesn> github: https://github.com/w3c/aria/issues/899

JamesCraig: basically, on a news site, every article kept saying "article" even though everything looked right
... so maybe we need more flexibility for inferred labels
... in particular <dialog> and <article>
... might not want to pick the first line, but if there's a first (unique) heading, that could be inferred
... in <dialog>, it might be useful to be even more flexible. if there's a logical first line of text, we could infer it's the label

jamesn: joanie is very against any heuristic fallback, so if we can define and glean general support, that's fine. but we have to define correctly
... need definitive guidance. gut feel is that it'd be the first child heading
... might not work with everything, but as a screen reader dev. you're free to do as you wish

mck: it seems to me like that's too loose, because if you have a bunch of descendants, that might not be a good heuristic
... i don't know how you'd limit it
... inference is tricky and kinda risky
... risk of having wrong label on these... for a dialog not huge, but for article could be a lot

JamesCraig: I think this would be lower in priority than title. only if there was no label conveyed would this apply

Stefan: I'm in Joanie's camp, this could have lots of implementations and could be complex
... some screen readers may behave, some may not
... it's a good idea, but it might often get corrupted

jamesn: i propose that someone who's interest, collect data on what might work for articles etc. and determine if we can come up with a programmatic, 90% correct idea

mck: I don't know if I'd support that, it's too easy to collect potentially junk data
... I'm agreeing, if its an absolute fallback esp. if the experience isn't optimlly coded
... some people accuse Vispero for not waiting on data, others accusing NVDA of the opposite - there's lots of perspectives
... idea that we're building in inference is an interesting proposal
... we should do so cautiously. data might not help

JamesCraig: the context is prioritizing needs of users over all
... if specification is too rigid, it can be challenging to make things work for users
... similar to this is browsers and layout vs. data tables
... even if something doesn't work, i might need to do something anyway. I wanted to, if possible, find a great solution for user agents and users even if spec and authors are wonky

Bryan: i agree, but I am concerned about if we open the door to this, we might see more bad coding practices
... if you go to devs and ask "do you want to label things or have it done automatically?" obviously they'd say yes
... we don't want to promote bad practices

mck: +1 to spirit of JamesCraig's intention
... ideally, we want to prevent the automatic thing

<pkra> bye

jamesn: this was a great discussion. JamesC, it sounds like you need articles to have an ACCNAME?

JamesCraig: I don't know if I'd use require, but if we land on it with no label, we just read role description
... particularly with the VO rotor
... i'm trying to make that UX better

jamesn: could you read the first line if nothing defined?

JamesCraig: we'd have to look into things a little more
... there is a risk of weird worseness, but if 90% is better, that's a win

jamesn: and author can override with a label

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

14 Feb 2019

Attendees

Contents