– DRAFT –
ARIA WG

New Issue Triage

<chlane> jamesn: respec might be doing that in #1773

<chlane> jamesn: file issue if needed

jamesn: notes that there may be respec dependencies here

https://github.com/w3c/aria/issues/1772

spectranaut: has a PR

https://github.com/w3c/accname/issues/164

scotto: is there value in columnheader and rowheader becoming part of the accname calculcation

scotto: questions whether the filer groked whether the they were hearing the column/row header info

scotto: if we were to add that content to the cells then we'd have redundant announcement

Matt_King: we would also super complicate the name calculation for the cells themselves

scotto: I don't think there is anything to do. I could see value as a fallback but I think there may be a good reason that this was never done before

Matt_King: should put a reason why its a wontfix

scotto: not one of my specs

spectranaut: Bryan or Melanie on the call?

spectranaut: feeling from Matt_King and scotto is close as a wontfix

Matt_King: reason is that it would break other things and keeping it from breaking other things would create unmaintainable complex logic

scotto: agree - would become very convaluted

Bryan: will comment

New PR Triage

https://github.com/w3c/aria/pull/1774

spectranaut: I will look at this

Deep Dive planning

jamesn: possibly popups

scotto: openui and popup attribute

<aaronlev> I can't do the popup deep dive August 18 or 25

<scotto> https://open-ui.org/components/popup.research.explainer

jamesn: Aug 11 for popup?

scotto: that works

jamesn: I will schedule

Review/revise mappings for input type=file

Review/revise mappings for input type=file

github: https://github.com/w3c/html-aam/issues/421

scotto: The mappings in HTML-AAM do not reflect the way the file input is rendered in all browsers today
… the mappings were good for IE and legacy edge but don't really work today
… as browsers not alligned how would we allude to this in HTML-AAM?
… should I call out the fact that browsers do different things and try to call out what they do?
… inputs where browsers do there own thing are a bit interesting
… or do  🤷‍♂️

Matt_King: are you talking about after button pressed or in the webpage itself

scotto: input file is a labelable control but you are not changing the accname of the choose file button

scotto: on webkit the label and name of the button get concatenated into a text string

scotto: chromium sets something with the content with aria-hidden = true which is a bug

scotto: the various differences here - can either document those

scotto: or open up bugs

Matt_King: more complex than just rendereing the button

Matt_King: how much control does the author have

Matt_King: after uploaded a file the browser is in control of how that is rendered too

scotto: yes - there is a lot to this

scotto: html-aam is wrong

Matt_King: greenfielding here - would be awesome if you couls say it maps to an openui file attachment widget. real life problems. the way it is shown makes it hard to make these consisntent

Matt_King: not an HTML-AAm problem

Matt_King: could say it maps to this kind of widget

scotto: the only issue is that the previous element would still exist

scotto: would help with newer stuff and not help with the legacy issue

scotto: also have another issue

scotto: with naming

jamesn: everyone wraps these and hides them

jamesn: don't think browsers will change

spectranaut: maybe we should just say there is no consistent implemention

Whitespace characters

"Whitespace characters" underspecified - 1.2 blocking

github: https://github.com/w3c/core-aam/issues/128

spectranaut: we thought was 1.2 blocking but decided it wasn't but we decided again that it may be.

spectranaut: we need someone to work on this

spectranaut: need to determine that the implementations all respect the same whitespace implementtion

jamesn: would like to see browser implementors looking at their code to determine what they are actually doing

jamesn: i18n issue

jamesn: aaronlev to look at what lib they are using for isWhitespace

aaronlev: need to know why this matters to users or authors

jamesn: will look for common defn for whitespace

<spectranaut> aaronlev: it seems like possible we should just update the spec to say if empty, not if empty or only whitespace characters?

<spectranaut> jamesn: I think this comes from the ARIA spec, and the problem needs to be fixed there too

<spectranaut> aaronlev: I think we should change everything to empty string, if it is empty string dont map anything else map

<spectranaut> jamesn: I think this was necessary, because they didn't want role description overrulled to blank

<spectranaut> StefanS: I think the spec only speaks of white space and never defines what white space is?

<spectranaut> jamesn: yes

<spectranaut> jamesn: aria 1.2 hasn't been reviewed, so we have to fix this in 1.2 regardless

<spectranaut> StefanS: we have candidates for definitions

<spectranaut> jamesn: but we need the implementation to all agree otherwise we can't publish until they do

multiple headings in hgroup

indicate what to do with multiple headings in hgroup

github: https://github.com/w3c/html-aam/pull/398

scotto: defered this until outline changes were resolved

scotto: the proposal is for extra headings within an hgroup outside of the highest level get mapped to a paragraph

scotto: or that we don't do anything and let invalid code be invalid code and validators would be the ones to inform authors of this

scotto: the other ask is whether we would be interested in creating a heading group role

scotto: to allow AT the option of letting users know that this stuff is all related to the heading

scotto: steve's thought otherwise is that there isn't any real boundary

scotto: these are the proposals

Matt_King: is the name heading group?

scotto: hgroup

scotto: original purpose was to contribute to the never implemented outline algorithm and authors could group headings together and that never happened

scotto: now the content model allows a single heading and other paragraphs to provide additional info

scotto: there are implementations which group a bunch of headings

scotto: we could do something about that or not do anything and have validators flag them as being in error and have authors fix them

Matt_King: hgroup could have h1 h2 ... h6 within them

Matt_King: only the h1 is supposed to be a heading and the others wouldn't be heading content?

scotto: yes but browsers never implemented it

scotto: purpose was to allow you to use these headings essentially for styling things

Matt_King: if people are doing for styling reasons

Matt_King: could be H1 followed by 2 H4s

Matt_King: the right thing from AT is P elements

Matt_King: no point in showing the boundaries

Matt_King: groups almost never help

scotto: do we want to specify that errant headings be Paragraphs

scotto: might be easier to have validators call this out

Matt_King: sounds more reasonable to me

jamesn: make validators shout loudly

chlane: is that a case for deprecation?

scotto: no - not now

column header roles

thanks to those who have done the triage

those who haven't please get to it