<Jemma> Scribe:Jemma
rrsagents, make minutes
<joanie> https://www.w3.org/2018/11/aria-charter
Joanie: new ARIA charter
<joanie> https://w3c.github.io/spec-releases/milestones/?rec=2019-12-19
<joanie> https://w3c.github.io/spec-releases/milestones/?cr=2019-11-21
Joanie: we have the deadline to meet, Oct 3 2019.
"Latest date to request wide review of the Working Draft Thursday, October 24 2019"
<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity
joanie: to meet the deadline of Oct. 24 we need to discuss about the scope for ARIA 1.2
jamescraig: we should not do password
from the list of "No consensus yet"
<joanie> canvas (#927)
<joanie> details (#928)
<joanie> embed (#929)
<joanie> input (type=color) (#930)
<joanie> input (type=date) (#931)
<joanie> input (type=datetime-local) (#932)
<joanie> input (type=file) (#933)
<joanie> input (type=month) (#934)
<joanie> input (type=password) (#935)
<joanie> input (type=time) (#936)
<joanie> input (type=week) (#937)
<joanie> object (#938)
<joanie> rp (also check with i18n) (#488)
<joanie> rt (also check with i18n) (#488)
<joanie> ruby (also check with i18n) (#488)
<joanie> summary (#939)
jamesn: aria details in the agenda later.
JamesCraig: aria-details with summary can be complex..
cooper: I think aria-deatil is less of high priority
Jamesn: explaining about the concept of "generic role"...
+q
<Zakim> MichaelC_travel, you wanted to suggest if you were creating a web component it could be substantially similar to equivalet HTML
jamesc: the reason for pushing
role parity is in part for testing.
... multiple browsers can have the same context and so that
they can consistently pass the testing.
... role parity can help each browsers can have consistent
result for automated testing.
I was wondering of what exact differece James and Matt have since I think you two are talking the same thing.
spe: from web dev perspective,
aria should be easily matched to html.
... I was wondering when JamesN talk about the complexity of
"label" what complexity he is referring to.
james: I was thinking about how we can make acc name calculation be easier rather than going through multiple steps of name calculation.
group is talking about "complexity"...according to the level of developer expereinces, or the case framework developer
jaemsc: Therefore, additional ways to encapusulate like Matt king mentioned may give the flexibilty to different audiences.
Joannie: by the end of this week, we may need to decide from three options, 1)forgot about this, 2) partial implementation for role mapping, 3)naming for authors need to happen so we will get the name right and etc till ARIA 1.3. The group is going with option 3.
<ZoeBijl> Mockup for an ARIA label replica: https://codepen.io/Moiety/pen/a9d69ca0bbdadabb89828daed014203d / debug link: https://s.codepen.io/Moiety/debug/a9d69ca0bbdadabb89828daed014203d
<Zakim> ZoeBijl, you wanted to ask if reversing referencing for labels would have implications for AT?
Joannie: The group agrees that
naming calculation should be consistent with HTML as much as it
can in principle. The group needs more time for gathering
naming calculation requirments. The related questions will be
the detailed ARIA workflow such as implmentation, APG work,
testing and more. The group will add the info to the notes for
now so that we don't confuse the Spec users. Please refer the
ARIA workflow documentation. https://www.w3.org/WAI/ARIA/workflow.
... If there is any issue like what Irfan addressed, plese file
the issue to ARIA git hub so that the group can disucss/look
into the issue.
https://github.com/w3c/aria/issues
irfan: do I file the issue individually?
joannie: avoiding the duplicate is preferrrable. please use your judgement. also the group does triage for the issues.
<Zakim> jamesn, you wanted to break
https://github.com/w3c/aria/issues/1001#issuecomment-527125274
<ZoeBijl> scribe: ZoeBijl
<Irfan> https://github.com/w3c/aria/issues/1001#issuecomment-527125274
<joanie> https://raw.githack.com/pkra/aria/braille-props-roledesc/index.html#aria-brailleroledescription
JD: I put a link to the latest aria-brailleroledescription proposal
as you may recall during the 1.1 cycle we came up with roledescription
role descriptions can be pretty long
braille lines can be pretty short
if you allow authors to do something they will likely do it
JC: Are we proposing braille cells or strings as values?
JD: we’ll get into that
What Peter tried to do is…
encourage ETS the ability to do this but discourage authors from doing this
I want to get a feel for, are we OK with landing this?
Peter has been working hard on this and ETS has use cases for this.
I will open up the floor
JC: I think it makes sense
I proposed roledescription a while back
like “slide” comes up a lot
A bunch of native implementations of screen readers
Like voiceover
They pronounce Button, but print btn to braille
<Jemma> https://raw.githack.com/pkra/aria/braille-props-roledesc/index.html#example-28
In example 28 we have “pln” to mean “planet”
What it should be is a string that is then interpreted by ??
In VO your braille API accepts a string and that is then translated into the braille string
JC: If I understand your question, yes
If we’re going to print it to the braille display we pull it through an interpreter
JD: I’m not disagree, trying to understand
Isn’t btn always btn?
JC: Braille is different in every language
JD: Isn’t a B always a B?
JC: In western languages, yes
But in Japanese braille it’ll probably be different
JD: Any author that doesn’t know which braille cells to put in probably shouldn’t put them in.
JC: VoiceOver has specific braille string that are shortened etc
For example btn for button or pln for planet
Let’s say the role description is “people”
for grade 1 it would be printed as the entire string
In different grades it could be just the letter “P”
MK: I’m still sorta confused James
roledescription is like aria-label already
the localisation is the authors responsibility
you localise roledescription you localise the label
<jcraig> I’m saying:
<jcraig> aria-brailleroledescription="⠏⠇⠝"
role is localised, the role names aren’t localised
<jcraig> should be:
<jcraig> aria-brailleroledescription=“pln”
<jcraig> from: https://raw.githack.com/pkra/aria/braille-props-roledesc/index.html#aria-brailleroledescription
MK: JAWS has its own
abbreviations for these things
... authors should provide a legend for the abbreviation on the
page
JC: I’m saying that the brailleroledescription value should be latin characters rather than unicode braille characters.
<mhakkinen> +1 to jcraig's suggestion
MK: Say you have the string “bl”
I wonder if it could somehow end up being blind
JC: I have a colleague that’s from Germany. They use their entire system in English, except for braille, which is set to German.
There are only so many braille characters
What I’m saying is leave the translation (latin to braille) to the screen reader
JD: I don’t know if this is the case or not
Is there a case where you have a task where ?? would contract braille
MK: I don’t understand in the proposal what is the method for communicating the dots in the string
JC: I can paste the rendered characters
JD: The intent was that the authors already know what the localisation is
MH: I think I’m not a fan of putting braille characters there
I agree with James C
<chris_> Screen readers already handle contraction for Braille, so naively I think the description should be a long form description in the localized language.
*JC demonstrates VoiceOver speaking braille*
<Zakim> ZoeBijl, you wanted to ask if someone can provide information on these “grades”?
JD: So we don’t want actual braille characters in brailleroledescription
Is there anything else?
JC: There are different kinds of braille
JN: That’s my recollection of why this is there
MK: For roledescription the issue might be a bit different
<jcraig> An explanation of braille formats. https://www.seewritehear.com/learn/an-explanation-of-braille-formats/
JN: Ah then it might’ve been for aria-label
JD: What if we make it that authors can put in a non-braille string or the actual braille
We’re not gonna have maths in there
MH: Weeeeelll…
JD: Allowing authors to put in
actual braille characters
... if they know what they’re doing
JC: Perhaps change the example to a non-braille string but still allow unicode braille input
Steer authors in the right direction
MK: That means that AT is required to do some preprocessing
to see which characters are in there
<joanie> https://github.com/w3c/aria/issues/765
Conclusion is in https://github.com/w3c/aria/issues/765
<melanierichards> scribe: melanierichards
<jamesn> https://github.com/w3c/aria/issues/1038
jcraig: there's a number of diff
ways to use your voice to control devices. Dragon Naturally
Speaking, Android has one in beta (I believe). MacOS, iOS, we
announced voice control. Soon to be released
... existing support in a number of these tools to use either
the rendered text, or the accessible label, to activate
it.
... rendered text is "more", label is "more about widgets", and
you can speak either
... any mail app usually renders the check mail button as an
envelop icon
<Jemma> https://developer.apple.com/documentation/objectivec/nsobject/3197989-accessibilityuserinputlabels
jcraig: what we've added to
public API in iOS 13 is accessibilty user input labels, label
synonyms
... we could render 1+ optional strings. "envelope" could be
one of those. Screen reader user would only hear the primary
label
... there's API that's currently on used by voice control on
iOS, but in theory could be used by [missed] keyboard
access
... 1+ optional things that can be used in addition to label to
get to the element quickly
... don't want users to have to memorize different labels
across apps
... not sure if this should land in ARIA, but seems like a good
group to start
... I'm not convinced ARIA because ARIA doesn't really have
concept of array of strings in a content attribute
... that's my proposal, questions?
mck: if it was part of DOM, are you saying that DOM would land some stuff in the acc tree? This has to get into a11y APIs to be useful
jcraig: yeah, say there was a property on an element that maps into APIs...the only problem with content attribute is what are you going to use for the string splitter? single quotes? Feels awkward
mck: so you're not suggesting we would add a new kind of attr value, like an array, in ARIA?
jcraig: I'm not suggesting that
fits into the normal DOM attr content structure
... closest we have is token list; space separated. But some of
these may have space in the string
mck: sure would be nice to have maybe JSON syntax for arrays in a content attribute?
[nervous giggling]
jcraig: I can come back with a concrete suggestion?
jamesn: seems reasonable, not 1.2 but can be worked on in parallel
jcraig: I could also take it to
WICG
... could propose as DOM rather than ARIA
mck: if there isn't a way to express in content, seems interesting. What would you actually propose in a PR in ARIA?
jcraig: IDL for extending element interface for an array of strings. But ARIA hasn't done that yet, closest is reflected attr so far
jamesn: can you still do it in a declarative manner that way? Probably want to do it declaratively
jcraig: that's why I took it here, why do you think declarative? and how would you implement in the DOM?
jamesn: I have a feeling authors will want to do this in a simpler method than have to add scripting
mck: seems like you're already doing scripting here/
jamesn: [gave example of simple form button]
jcraig: anyone know of precedent for overloaded attributes, define the attribute, redefine the attribute, etc in a declarative fashion?
[quiet room]
jamesn: I'm not adversed to doing just in IDL, if it solves it for most users
<jcraig> such as foo=bar foo=baz, etc? or foo1=bar ffoo2=baz… I don’t know of precedent to that effect.
jamesn: solving for 90% sounds better than doing nothing
mck: if you did it in DOM, not you're for sure limiting it to scripting anyway. No advantage in ARIA unless we come up with declarative way to do it
jcraig: advantage is we can pull
ARIA into contexts other than declarative interface
... could be a standalone spec as well
<aboxhall> `data` attribute might be a useful precedent?
Jemma: an ARIA property with a token list
<jcraig> tokenlist is space separated, but some of these strings may include spaces
Jemma: there's one for aria-dropeffect property
jcraig: token list is space-separated, and these strings might include spaces
mck: you could use another split separation character that you'd never include in a label, like a semicolon
jcraig: or a vertical bar
[Matt and James C agree feels messy]
mck: decision of what character
you choose may have ramifications down the line
... maybe people go crazy for this kind of type
chris_: agree token list doesn't
work here, there are characters that are unlikely to be spoken,
but that seems special-casey to me.
... if we extend this concept down, and some are
space-separated, others have different separator. Spaces are an
innappropriate separator. Separator chars are assuming a
certain context, like a certain spoken language
jcraig: I suppose we could
backslash our spaces but that seems dirty too
... in those cases where we think it's rare to be used we could
use backsplash
[noises of dissidence]
<Zakim> aboxhall, you wanted to discuss dataset
jcraig: open to discussion, don't think it should be a content attr
aboxhall: one places where we
have precedence is associate arrays dataset. That's specially
specced in the HTML spec, this would have to be specially
specced too. Tricky
... aria-labelsynonym1, -2, -3
Jemma: we're not ready for implementation details yet, just brainstorming?
jcraig: yes
Jemma: what's next step
jcraig: I'll come back with a concrete proposal
<chris_> Link for dataset https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset
jcraig: Alice's suggestion is the best one so far
<jcraig> clarifying: "Alice's suggestion is the best one so far”
<jcraig> I will not be including a declaritive content attr approach in the proposal, but off the brainstorming ideas, Alice's suggestion is the best one so far
<inserted> scribe: ZoeBijl
<jamesn> "I propose a single segment on the topic of "Effects of ontology on table and grid" for discussing approaches to resolving the following 3 issues:
<jamesn> Issue #1022: (Consider prohibiting name from contents for rows in static (non-grid) tables.
<jamesn> Issue #1008: (Should aria-selected be allowed on row, columnheader, or rowheader in table?
<jamesn> Issue #79: WAI-ARIA 1.1: Cell and gridcell, which proposes depricating gridcell.
<jamesn> I don't believe we need non-WG participation.
<jamesn> I think it will take a solid hour or more to clearly layout the problems and weigh options."
https://github.com/w3c/aria/issues/1022
https://github.com/w3c/aria/issues/1008
https://github.com/w3c/aria/issues/79
ZB: Those are the relevant issues for this topic
MK: Highlevel, there are some places in ontology where we have the same role can either be a widget or a structure
And some places where we have two distinct roles
One for the widget and one for the non widget
One place where we have the same role for role and structure is row and separator
Normally like a row in a table is always a structure
A row in a grid is always a structure
A row in a tree grid can be both
Because it can be selectable
So that’s the same role for widget and structure purpose
Another example of this is separator
If it’s focusable it’s a widget
If it isn’t focusable it’s a structure
In some places we have the reverse
An example of that is grid cell and cell
If you have a cell in table
You use the cell role
but in a grid you use the grid cell role
So we have three issues open related to this
One is calling for the elimination of the grid cell role
That’s 79
Goes back aways…
1008 and 1022 are related to row
I can just see the writing for this “name prohibit except when…”
Same thing with rows being selectable
It’s only… I forget the properties that are on selectable
But there are certain states that only apply when it’s a widget
Not entirely sure what the best way to resolve these is
But in the future… ??
If the row has a pattern related to selectable then it’s a selectable row
but the way he ontology works right now
if it doesn’t support selectable directly it’s inherited from somewhere
The way it’s related to ontology is how ??
Certain states are either allowed or required and it becomes complex for both authors and validators
But if we were to go the path of adding more widget roles
So that summarises the issue
<Zakim> ZoeBijl, you wanted to say we should make it as easy as possible
<jamesn> ZB: earlier discussed making things easier for authors. Would different roles make it harder for authors?
<jamesn> For row for example in a table its a structure and if can focus its a widget
<jamesn> MK: the naming thing is interesting for row - if you allow rows to be named.... normally in a treegrid you want the name to come from contents but there are cases you want the name to come from a portion of the contents
<jamesn> if we prohibit naming on row except in treegrid - is that complicated?
MK: You should never make a row focusable in a grid
I could be wrong about that
JD: What if you had a message list
MK: Should you be using a grid?
I think it should probably be a tree grid
JD: The folder list could be tree grid
ABR: Another example could be a spreadsheet application, you highlight a row or column as a whole for some operations. Could be implemented with a separate header/label cell, but conceptually you're focusing the row.
MK: I heard of it being selected
But I’ve not come across an application of focusing the entire row
ZB: I do see people making rows focusable
Not sure that entirely related, just want to put that out there
MK: We should take a consistent approach to resolving all three of these issues
One approach is to say we have some legacy things and we accept that for what it is
Meaning we’d keep grid cell
How about table and grid
We added table
Because grid was supposed to be the interactive version of table
For all the things to go inside
Maybe it’s enough for the ancestor to be grid or table
Which would tell you whether it’s ineteractive or not
ZB: Makes sense to me
MK: it would make ARIA more forgiving
ZB: I’m in favour of deprecating grid cell in favour of cell
MK: How do we then deal with… ???
It would say “if context is a grid”
if context is…
We would never have it the other way around
JN: We have some inconsistencies anyway
JD: That sounds like a mistake
JN: Oh no it does
It inherits it, I missed that
MK: When you’re doing inheritance…
We need to have a script to propagate that
JD: We’re already doing this for some other things
So we I don’t see why we can’t for this
ZB: Are there implications to deprecating grid cell?
MK: We’d have to change how we list the supported and inherited roles
ABR: It would need to stay around as a deprecated synonym
MK: Something that would be improved is row and column header
We could have something like “only in the context of grid are they selectable”
JD: The funny thing is that it would take more time to come up with the script than it would be to implement the change
MK: You would need in the implementations make sure that certain things are disallowed
JD: That’s already in place for a lot of things
Chromium for sure
ABR: They’re already dealing with invalid attributes anyways
Some perhaps better than others
JD: I think it’s easy to solve in terms of implementations
JN: Do we have agreement on this
MK: we would say they’re not allowed when the context is table
In 1008
But is allowed in grid
For validators that are consuming our spec programmatically
We should try to be cognisant to make sure that we do this in a way that’s consistently parseable
There’s the ARIA query project
ABR: For these attributes that will be conditionally valid we need a machine readable format for that condition
JD: we have a different entry for…
Different condition for a table
MK: Is it possible for us to have two rows
JD: Not saying we should do this
But brainstorming
Could we have “cell (inside table)” and “cell (inside grid)”
MC: Someone said that there is already some complexity to this
Parsers need to be more contextually aware to process this
JD: That’s what we’re doing with this change (limiting naming of rows)
MC: I thought there was a reason for us keeping grids and tables separate
JD: We’re not changing that
*some discussion about aria-owns*
MK: The question was do we add a bunch of roles prefixed with “grid” or do we drop the grid ones that we already have
ABR: Authors get ?? wrong so often
If we can make more of those conditions implicit
Ratehr than alloweing authors to make invalid combinations
That would be a win for both authors and users
ZB: +1
ABR: It does make validation harder
But it follows the order of constituents
MC: I think we need to put extra clear flags about this in the spec
A note to implementors
*JD does hand wavey thing*
It’s something that could be easily missed by implementors
ABR: What Michael said goes back to what Matt said in the beginning
We already have cases where there are a lot of exceptions based on context, e.g. the separator role
MK: We did it in the section related to naming
<scribe> scribe: ZoeBijl
*short discussion about fixing the minutes*
MK: It might be, I don’t know if it’s nicer for the reader if it’s parenthetical or if it’s a separate list
JD: I’ll update the issues
the conclusion is that we’ll deprecate “grid cell”
It’ll be synonym
MC: We should have a path for deprecation
ABR: We encourage authors to move to cell
MC: Not just look at the change log, but make it a major change
MK: Do we want this to be 1.2?
It might be wise to take the same approach as we’re taking with naming related stuff
“This is our plan and we can merge stuff” but let implementors and AT to get on board
JN: What’s the hurry?
MK: Exactly, there’s no hurry
JD: Let’s move this to 1.3
MK: If we resolve 79 by changing it to a synonym
With deprecation we have more arguments for changing the APG
Make grid cell a synonym in ARIA 1.2 and plan to deprecate grid cell in ARIA 1.3
JN: ??
ABR: It’s probably good to focus on checking the implementations as to whether making “grid cell” a synonym of “cell” actually works
Make sure “cell” actually works in a “grid” role
MK: That’s a good point
That could be a test criteria
We don’t want o mess around with the implementation details between now and October
That would be a nightmare
Would be able to resolve 1008 and 1022 in the way we just discussed without deprecating “grid cell”?
I guess we can’t do it with row and column header
We already know that row works in grid, treegrid, and table
Or are we prohibited in some way
JD: I think that’s gonna be easy
They fixed the issue in Gecko
And it was never an issue in Chromium
JN: The gecko bug says that if it has an explicit ARIA role it will calculate the name, if it doesn’t have an explicit role it will not
MK: …allow aria-selected for that specific state
JN: That makes sense
MK: Also wouldn’t have to change the APG
JD: In terms of validation does that count as authoring errors?
MK: In the aria-selected section
of section 6
We also need to change it there
It has been changed in allowed roles
JN: All of that stuff is generated
MK: Ohh the used in and allowed lists are generated automatically
JN: …when someone updates the scripts
But yeah
<Jemma> https://github.com/w3c/webcomponents/issues/826
JN: we’d like to update where we are on 1.2
Which came mostly from where you are
you being the web folks
There are a lot of things we’d like to get parity for in 1.2
Some of us are not entirely sure why we’re doing some of this work
LW: If memory serves me right
Google was a real champion of role parity
Especially Geroge Russel
You should be able to extend HTML things
or create entirely new ones
There are two types of custom elements
There are three specs, shadow DOM, templates, & custom elements
<aboxhall> templates, custom elements
This lets you take an excisting HTML element and extend its capabilities
The code can get really ugly so it’s not really popular
And webkit doesn’t support custom elements (?)
The purpose is to replicate HTML in all it’s glory
JN: There are some roles/elements we don’t plan to implement in 1.2
Because we’re not sure how to
So we’re aiming at incremental improvements
LW: That would be fine
MK: James Craig has proposed a way to move forward
JC: my way would improve the testing case but not the web components case
<chris_> 'testing'
JN: So once we decide we’re OK with not having everything in 1.2
We move to what do we do after 1.3
???
LW: I can only assume so
MC: Assuming we also finish role parity
JN: Depends
AK What’s attribute parity
JN: Anything to do with HTML attributes
ABR: Any attribute that has to do with accessibility?
JN: That’s the defined list
MC: If that’s complete…
I think there’s a lot of stuff that’s not mapped
distinguishing not mapped because it shouldn’t be vs. not mapped because it hasn’t been mapped yet
JD: I mean not mapped on purpose
JN: some things are exposed but not directly mapped
AK Do you get the attribute or the inherited concept?
JC: The ??
But it’s effectively the same thing as parity
<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity
JD: Most of these are at least partially done
abbr for example
The big ones are under the “no consenses 1.3”
But a lot of them are input
For a lot we’re not sure how to deal with them
embedded object and ruby stuff
summary and details is gonna take us some more work than we anticipated
Like canvas
If you look at the “no consensus list” and see something that you absolutely need to have please let us know
LW: proxying for my colleagues, but we will let you know
Thank you for doing that
You’ve done an astonishing job
*round of applause*
JN: Thank you
ABR: Are there other cross issues that we should discuss with Léonie?
I don’t know the status of shadow DOM etc
*something about shadow DOM*
AB: I have a PR open about element reflection
Has been open for over a year
we’ve been going back and forth during that time
There are a lot of open questions around it
<jamesn> https://github.com/whatwg/html/pull/3917#pullrequestreview-189973949
<jamesn> https://github.com/whatwg/html/pull/3917
AB: intended for custom elements, which Léonie mentioned earlier, you can get the internals
That allows you to specify, among other things, ARIA and semantics
These are superseded by DOM ARIA attributtes
*some discusssion about default attributtes*
AB: Any of the ARIA state attributes would change dynamically
AK: The first itteration fo this API exposes form elements
ABR: So you said you came here expecting a discussion about what the ARIA WG should focus on
AK: If you take aria-describedby there is some deligation
Because the custom element could say “hey, it’s actually described by this element”
Because the details aren’t exposed to the outside
Something paralel to the custom ellement can’t know about the custom element’s internals
AB: Having trouble thinking of a usecase
AK: If you have a video element
it might have images for posters and you don’t want those for the name calculation
MK: YOu can’t chaing labelledby or describedby I don’t think
AK: You can’t reference IDs in the shadow DOM
*missed a part*
MK: but that couldn’t contain describedby references
AK: I was assuming it was text content
Like there are parts that aren’t relevant for a described case
AB: I’d be interested to see some more use cases for this problem
Say you’re implementing a custom combobox
POerfect example for active descendant
My active descendant is element 4
But how do you expose that?
AK: But it’s the CE’s shadow host?
AB: yes
AK: So you could set it to the shadow tree descendants?
AB: custom elements wants to refer to something inside the shadow host
AK: Is it the shadow tree?
AB: this is the labelledby case
But that’s bringing another element on the page into the mix
<zcorpan> https://github.com/whatwg/html/issues?q=is%3Aopen+is%3Aissue+label%3Aaccessibility
<tink> SP: Would like to discuss accessibility issues in HTML, and also how we (the WHATWG) can work more closely with the accessibility WG.
<tink> ... There is a list of issues on our repos that have the accessibility label.
<tink> ... The oldest of the open issues is to suggest a warning about the outline algorithm.
<tink> DD: There is an outline algorithm that is based on the idea that nested headings can be treated as lower level headings, but this doesn't match with current reality.
<tink> ... two ways to solve this, Anne has a proposal, and the other is to update the algorithm.
<tink> MK: Can you give more background on where the algorithm is implemented and/or used, and how that affects the AT experience.
<tink> DD: It was never really implemented.
<tink> ... it's more authoring guidance than implemented in browsers.
<tink> AVK: Implementing the algorithm in the browser is expensive.
<tink> DD: It's what the AAM has chosen to ignore the outline algorithm.
<tink> SP: It affects AT users in terms of how they navigate through headings.
<tink> JN: AT can also read the heading levels as well as navigate by them.
<tink> ... Wondering what we (the ARIA WG) can do to help?
<tink> DD: If we want to keep pushing for this algorithm, your help making that call would be appreciated.
<tink> MC: We should work out with the APA WG for review on this.
<tink> AVK: APA?
<tink> MC: Accessible Platform Architectures WG.
<tink> JN: It's the HTML AAM that'd need updating.
<tink> MC: APA is probably best placed to answer this question.
<tink> MS: Part of our expectation was that people who had strong feelings might be here, people liek Steve Faulkner, but they're no, so this might not be the best time to have this discussion.
<tink> JN: I'm familiar with the issue.
<tink> DD: We should re-spec the outline.
<tink> JN: The warning should be put in until that happens.
<tink> MS: There is a warning in the W3C conformance checker.
<tink> ...MS: The validator issues a lot of warnings, including about bad heading patterns.
<tink> SP: The validator also shows two different outlines.
<tink> MS: The validator is one of the few places where the outline algorithm is implemented.
<tink> AVK: We have an accessibility Github team, and we'd like to add more people.
<tink> DD: I'd like to hear from this group, about what you're intefrested in.
<Jemma> https://github.com/whatwg/html/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+aria
<tink> LW: How many accessibility issues are open?
<tink> SP: 20.
<tink> ABR: An issue about a radio group element, which gets to the idea, should HTML have parity with ARIA roles?
<AmeliaBR> Outline algorithm browser bugs: Chromium https://crbug.com/365070, WebKit https://bugs.webkit.org/show_bug.cgi?id=131920, couldn't find one for Firefox
<tink> JMD: What if we hada non-numerical heading element?
<tink> JN: Read the outline issue, it's all in there.
<tink> MS: Backwards compatibility is part of the problem.
<tink> SP: Argument is that it's better to have a flat list of headings, than nothing.
<tink> JC: In the case of <div role="heading"> with no explicit role, it's exposed as an h2.
<tink> ... There are screen reader commands for "jump to heading at next same level", which is useful functionality especially in large documents.
<tink> ...I'm not aware of any disagreement internally with the current proposal for the algorithm, it isn't high on our priority list.
<tink> AVK: There is a carrot in terms of styling too.
<tink> SP: Tested James' example and according to devtools it's an h2.
<tink> LW: Not convinced that breaking backwards compatibility with headings would be terrible, because headings are almost always broken hierarchically in the wild at the moment anyway.
<tink> JC: Having some kind of HTML data provider that is queriable with scripting would make somethings, like scrolling patterns, much easier.
<zcorpan> https://github.com/WICG/virtual-scroller
<tink> DD: There's a proposal for virtual content.
<tink> ... It's better to encourage people to put the data in the DOM, but right now that's expensive, and so we'd need to improve that first.
<tink> ... So the cost is based only on what's displayed on the screen.
<tink> JC: There might be hundreds of thousands of things in the dataset.
<tink> DD: If it's a vast dataset then that proposal is intended to help.
<tink> JC: Making it possible to use find functionality to search the dataset would be a useful feature.
<tink> DD: I think the virtual content proposal had server hooks?
<tink> AB: No, it's based on scrolling.
<tink> ABR: Maybe an issue on that proposal to ask for hooks?
<tink> ...If it was based on user events, like when a user tabs into the area, or when a user searches for something inside the area?
<tink> DD: You'd want a hint to the server, "they want the next heading" etc.
<tink> JC: Platform acc API have something similar.
<tink> AVK: It would be very observable that you were using AT.
<tink> ABR@ If there's just a generic "load more" API, that might help with that.
<tink> MK: Why would it make it observable you're using an AT?
<tink> JC: I think Anne was saying there is no UA that does something like heading navigation.
<tink> MK: GoogleDocs does.
<tink> JC: That's the application though, not the screen reader/AT.
<tink> ABR: On the issue of a hidden-like attribute, that's a case of speccing something that has strong use already on the web, a method to hide things visually but not from AT like screen readers.
<tink> SP: Like display:none; but still available to screen readers?
<tink> JMD: aria-hidden="false" was intended for this purpose, but it's not been implemented.
<tink> SP: Since developers use CSS hacks to get this, it shows there is demand for it.
<tink> JC: There is demand but there are also implementation challenges.
<tink> ... Webkit supports aria-hidden="false" to a degree, but it got complicated because of the rendering block/tree.
<tink> AVK: You used a flattened tree to create the acc tree?
<tink> JC: We ended up making it so that you could only hide something one element deep I think.
<tink> JN: I think we've taken aria-hidden="false" from the spec?
<tink> MK: How? I don't remember.
<tink> JC: Think it wasdeprecated.
<tink> SP: You can use aria-label/labelledby to add information for a "more" link.
<tink> JN: I've seen hidden text used in situations where you use something like the <del> element.
<tink> MK: Or where there's no visual heading but a navigation heading would be useful.
<tink> JN: Could use <span role="heading aria-label="heading text">...</span> or something?
<tink> LW: Does aria-label get exposed on that?
<tink> SP: headings have an accessible name so I think so.
<tink> JC: Perhaps an @screenreader CSS media query?
<tink> AB: Often wanting to do this is a design flaw.
<AmeliaBR> The CSS version of this feature request: https://github.com/w3c/csswg-drafts/issues/560
<tink> .. there are somethings legitimate use case, but I wonder what proportion they make up?
<tink> MK: Another case is stuff that gets displayed only on hover or focus, but when you browser with the virtual cursor you want it there all the time.
<tink> JN: So the question of whether we want equivalent HTML elements for all ARIA roles?
<tink> ABR: Yes, issues 4180 on the HTML repo, and #2463 on HTML also.
<tink> JC: Switch was added to ARIA 1.1 because checkbox on/off wasn't sufficient for the tri-state switch controls being used on mobile.
<tink> MK: This gets into what you should develop using ARIA and script, and what you shouldn't. Where do you draw the line?
<tink> ... Seems HTML should be the ones to draw the line here.
<tink> JC: There are things like the icons that could be changed if it was a native feature.
<tink> ABR: To the more general question, are there roles that exist in ARIA that should have HTML equivalents?
<tink> AVK: If there are use cases it makes sense.
<tink> DD: My team has been working on this, switch, but also other elements.
<tink> ... It's hard to ship new elements, because getting developers to say "we'll replace our thing with a native thing", because of librarries and other reasons.
<tink> ... It's hard to extend. Last time we tried it was <dialog> but it only has one implementation.
<tink> ... There are tactics, one I've explored is using custom elements and technologies like that, but it's just hard.
<tink> LW: Have there been successful examples where a pattern has been implemented natively and been taken up?
<tink> DD: Input elements like email perhaps.
<tink> MK: details and summary.
<tink> SP: video and audio elements.
<tink> DD: There is a discussion tomorrow about switch.
<tink> ... author focus handling is limited to tabindex and that's a problem for the switch pattern.
<tink> ABR: What about arrow based navigation like cycling through a set of radio buttons or such?
<tink> DD: And whether tabs in a tabset are arrows or tabs.
<tink> SP: What's needed?
<tink> ABR: A way to do these things that doesn't need event listeners.
<tink> DD: Something like a scoped tabindex?
<tink> AB: To say this container groups a set of similar elements that should be navigable in a certain way.
<tink> ABR: So the container would get the tabindex, then aria-activedescendant could be used, but you have to listen to all the keypresses yourself.
<tink> JC: There are some proposals in the AOM that look at user input events, and some semantic events, that could be interspersed with existing events.
<tink> DD: Are people familiar with the behaviour in chrome, and possibly others, have implemented where you tab between the three date fields in a date picker?
<tink> ... currently it's tabs.
<tink> MK: Not aware, would be good to see an implementation test case.
<tink> DD: I can share one.
<tink> ... But you tab through the three day, month, year fields inside it.
<tink> JC: So it's a single element with three tab stops?
<tink> DD: Yes.
<tink> AB: Like a video element has controls.
<tink> JN: On a date heavy page it sounds like a lot of tab stops.
<tink> MK: For a screen reader user it's hard to have to keep moving between fields to find out which year the month relates to etc.
<tink> AB: A related question of things that are tab traps.
<tink> ... things like modals.
<tink> MK: Also non-modal things with application behaviour.
<tink> ... Where there are containers with their own tab ring, but that you can navigate to using f6. Replicatingthat on the wbe is hard.
<tink> AVK: Does this relate to focus groups?
<tink> DD: It's only at the document level.
<tink> SP: The concept could apply to this though.
<tink> ... Could specify that two elements are two different focus groups, then have a feature to move between focus groups.
<Domenic> Example of native <input type=date> with three tab stops: https://boom-bath.glitch.me/native-input-date.html
<tink> AB: Yes, focus groups, and modals, all related.
<tink> ... GoogleDocs grid view is a good example of where this behaviour is implemented.
<jamesn> scribe: jamesn
<joanie> https://github.com/w3c/core-aam/issues/52
JD: this is 1 of 2 issues - not the main issue
<joanie> https://github.com/w3c/core-aam/issues/49
Added the other issue
SF filed that FF is caluculating posinset and setsize when there is a separator as separate sets
<joanie> Section https://w3c.github.io/core-aam/#mapping_additional_position States
<joanie> "Otherwise, if the role supports aria-posinset and aria-setsize, process the parent (DOM parent or parent defined by aria-owns), counting items that have the same role."
the other issue - issue 52
<joanie> This is not correct. A menu should count all the menu items no matter the type (menuitem, menuitemcheckbox, menuitemradio) not just items of the same role
Aaron stated same platform role - but that doesn't work on all platforms
posinsset and setsize - what are they supported on?
do we know what would happen with associationlistitemkey and associationlistitemvalue
JD: to me the questions are - if you have a separator and don't have a group object - do you reset your count every time you have a separator
MK: the separator is not intended
to be a semantic thing - but a visual presentation thing
... they never get exposed
JD: I've seen menus where you can arrow to the separator
MK: if you want grouping in a menu you want a group
<JD updates the issue>
MK: we don't have the concepts of various required owned element things
<BGaraventa> I don't think I have the right dial in code, the line is sielent
<BGaraventa> nvmind, I hear you guys now
<joanie> scribe: joanie
<jemma> http://a11y.pro/combobox-TPAC2019/
The above link is to Matt's presentation
The presentation doesn't directly address HTML issues yet, but we'll talk about them.
http://a11y.pro/combobox-TPAC2019/#/2 (Evolution of the Combobox Structure)
Matt: In 1.0 only a listbox could
pop up and it was owned by input.
... Now we have a div wrapper with a text input with a sibling
element which pops up.
... You can construct this relationship in two different
ways.
... The relation between the pop-up and input is
aria-controls.
... The relationship between the wrapper and widgets is an
owned relationship.
http://a11y.pro/combobox-TPAC2019/#/3
Matt: Why did we change it in
1.0?
... Because of aria-owns, listbox is a child of textbox.
... Screen reader users can perceive listbox options only when
interacting via keyboard.
... Only way to get access to the options is that focus change
events come as a result of aria-activedescendant + use of arrow
keys.
... If you're using any type of touch device or are in reading
mode, you're not going to see any of this.
... That is the problem we wanted to solve: We didn't want the
listbox inside.
http://a11y.pro/combobox-TPAC2019/#/4
Matt: Regarding the 1.1
structure, the div has the combobox role, but it isn't
focusable. What's focusable is a textbox.
... So it's not actually clear what that textbox is when you
Tab to a combobox. What is the screen reader supposed to say
and do?
... This is something we didn't really define. Plus it's a
pretty different way for screen readers to have to
handle.
... The other problem we ran into is when you're naming this,
WCAG says you have to name the input because it's
focusable.
... But you also want to name the combobox itself. So what do
we do?
http://a11y.pro/combobox-TPAC2019/#/5 Has a summary of all the structural issues in 1.0 and 1.1.
Matt: In addition to the
previously-discussed issues, the container adds unnecessary
complexity.
...
Does not correspond to anything visible in the UI.
Does not add value for screen reader users.
Like requiring a wrapper around a menu button and the menu it opens.
http://a11y.pro/combobox-TPAC2019/#/6 Has proposal for 1.2
Matt: I propose we treat combobox
similar to a menu button that controls the menu.
... The slide says "text input" but it doesn't have to be a
text input; it's an input.
... Browsers could still support the 1.0 pattern. It's pretty
straightforward.
<BGaraventa> +q
Matt: But we'd nuke what we're
doing in 1.1 and replace it with what I'm proposing for
1.2
... Namely, a listbox controlled by an input.
... The 1.2 version can be found here:
https://raw.githack.com/w3c/aria-practices/aria1.2-combobox-proposal/examples/combobox/combobox-autocomplete-list.html
... In testing, the 1.2 version is working out of the box in
both reading mode and interaction mode.
... All of them see the combo box, present the combobox, can
perceive the listbox, etc.
... There are a few bugs, but the basics work.
Matt: There's also a link to it in the ARIA pull request.
BG: Are you using aria-activedescendant as the user up and down arrows?
Matt: I believe so, yes, but I
would have to look.
... I took the 1.0 version and changed 2 lines of code, one in
html and one in JavaScript.
... I changed aria-owns to aria-controls.
... I had to make a similar change in the JavaScript because it
was using an attributte selector, looking for aria-owns.
BG: I've seen people try to put the listbox inside a button. We want to discourage that.
Matt: At this point in time, we don't have an example of a combobox which doesn't have an edit. But if we make this change, we'd of course also want to write such an example because it's a very common use case.
http://a11y.pro/combobox-TPAC2019/#/8 Has Related GitHub Issues
Matt: A couple of these have actually been closed, but the question is which changes we need to support if we go this path.
https://github.com/w3c/aria/issues/998
The Combobox 1.0 design pattern references incorrectly include aria-owns instead of aria-controls. #998
Matt: This issue is confusing people because where the property goes.
https://github.com/w3c/aria/issues/776 aria-controls a required property for Combobox?
Matt: All of these issues stem
from the fact that we have the combobox wrapper and the thing
which is not a combobox (i.e. the input)
... If we don't have a wrapper and the input itself is the
combobox, it's unambiguous where the aria-controls goes.
... So making this proposed change will solve these issues.
http://a11y.pro/combobox-TPAC2019/#/10 Naming issues
893: 1.1 Combobox pattern endorses unlabelled form fields
909: Clarify combobox label placement
1046: Does combobox require an accessible name?
Matt: The screen readers have
never exposed a wrapper before for a combobox, so why would
they expose a wrapper?
... So again, these three issues get solved with the 1.2
proposal.
... Those are the structural problems. Now I want to talk about
the definition.
... 1.0: A presentation of a select; usually similar to a
textbox where users can type ahead to select an option, or type
to enter arbitrary text as a new item in the list. See related
listbox.
... In 1.1 we made it a lot more clear.
... A composite widget containing a single-line textbox and
another element, such as a listbox or grid, that can
dynamically pop up to help the user set the value of the
textbox.
... One of the problems here is that historically there are a
lot of comboboxes in the world that don't have a textbox.
... We kind of drewe a line in the sand, saying essentially
"these are not comboboxes"
... We've received a large amount of pushback as a
result.
... There's an issue in HTML-AAM regarding mapping of select
element with size of 1.
... Another conflict I call the "readonly conflict"
<input type="text" role="combobox" readonly>
Matt: You can select the text,
but it gets announced as a read-only combobox. This is really
confusing.
... Because the popup functionality that allows you to change
the value isn't disabled, yet it's spoken as readonly.
... The purpose of having this attribute on the input is so the
end user can tab to the input and examine and select the
text.
... Authors get the info for free.
... But you can change the input from the popup, so it's not a
readonly input.
Amelia: Do we have a way to override this, like aria-readonly="false"?
Matt: But what would that do?
JN: Who wins?
Matt: But that might cause it to
be presented as an "edit combobox" which is wrong because it's
a select box.
... We also have the issue that in HTML you cannot use readonly
and required on the same thing.
... The goal is that we want input type="text" readonly
functionality, but we don't want it announced as readonly. But
I don't know how to solve that yet.
http://a11y.pro/combobox-TPAC2019/#/13 Proprosed 1.2 definition
Matt: There are loads of changes
here.
... An input that controls another element, such as a listbox
or grid, that can dynamically pop up to help the user set the
value of the input.
... The input could be a textbox, but it doesn't have to
be.
... The difference is that you could take a button, give it a
combobox role, give it a label which would be separate from the
value, and make it required (which you cannot do on a
button).
http://a11y.pro/combobox-TPAC2019/#/14 Summary of 1.2 Changes (PR 1051)
Revise definition of combobox to encompass implementations that do not support text editing, such as some implementations of the HTML select element by browsers.
Revise description of the structure of combobox so the element with the combobox role is the focused element instead of a wrapper that is not focusable and the relationship with the popup is defined by aria-controls.
Change the super class to input from select so it describes the actual structure; select is a composite and the revised combobox structure does not include any focusable descendants. This also has the beneficial side effect of removing aria-orientation, which is not applicable.
Add aria-activedescendant as a supported property because it is no longer inherrited from its super class.
Remove all required owned elements. A combobox no longer has any descendants.
Change section 2.3 (id=“managingfocus”) to remove combobox from the list of composite widgets and for clarity and compatibility with revised combobox structure.
Editorial revisions to the definition and description of the aria-activedescendant property to reflect the changes to the combobox structure.
Matt: To the best of my
knowledge, this fixes all the open issues related to combobox.
It does NOT solve the readonly issue I mentioned. (Not
currently filed)
... We're done revising combobox is we make these changes.
Melanie: I really appreciate all
the work that went into this.
... The one challenge is, if we make another revision, we want
to make sure it's airtight.
... In UIA a combobox is a composite container.
... I would be concerned about supporting this proposal because
it doesn't make sense in my API.
Matt: How does it not make
sense?
... We don't have to make any mapping changes in any
platform.
Melanie: But the structure is different from what we're expecting.
Matt: We tested this with Narrator and Edge and the user experience is better with the 1.2 example than the 1.1 example.
Melanie: But if it doesn't align
with the structural assumption UIA has, there may be breakage
later.
... And then you would have to write web specific code.
Jemma: I'm trying to understand your concerns.
Melanie: There would be no work
on my end (browser) to support what Matt is proposing.
... But the accessible hierarchy doesn't match what we see in
the native equivalent.
<melanierichards> https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-supportcomboboxcontroltype
Jemma: What kind of damage is done when there's a structural change?
Matt: Do you assume a wrapper for
a menu button?
... Do all the structures in HTML match what's in UIA.
Melanie: That's the challenge. We
do the best we can. We provide access via the AriaProperties
property.
... What concerns me is that we are choosing to go against
what's exposed via the API.
... Can we work with screen reader developers to make the 1.1
version work better?
Matt: Right now we have so much
author confusion with the 1.1 because it doesn't look like
anything people are familiar with.
... The thing that gets focus isn't the thing that has the
role.
... That's unlike anything else we have in ARIA.
... We're always telling authors to focus the thing that has
the role.
... But here, in the 1.1 combobox, we're telling authors the
opposite.
JD: This can be solved in ATs.
Matt: You can hack, but.... With
most composites you have multiple things inside which can get
focus. And you manage the focus.
... the user sees the container, then the child.
<jamesn> JD: like the proposal as simpler. Other thing just say on the record
<jamesn> in response to Melanie - there are a bunch of things which don't look like neative
<jamesn> and screen readers have a bunch of hacks and workarounds - all screen readers have to deal with "the web"
<jamesn> seriously while i sympathise - in UIA it may look different but the rest of us just cope with it.
<jamesn> if the problem is you have a combobox container - you ascend the ancenstry. if nothing has cuased the listbox to be presented then providing context is something screen readers do
<jamesn> if you tab to a window the window ancestor should be presented. Why don't NVDA and JAWS look at the textbox and see there is a combobox ancestor and present as a combobox
<jamesn> MK: could special case it... could have a wrapper without calling it a composite...
<jamesn> JD: how is this special?
<jamesn> MK: the grid never gets focus. the grid and structure get exposed.
<jamesn> JD: but why does that happen?
<jamesn> JD: If i land in a cell in the middle of a grid... the screen readers say i'm in a table ..... i guess I should tell the user about the grid
<jamesn> JD: why can't screeen readers do that for comboboxes
<jamesn> MK: things aren't aligned
<jamesn> JD: so many things aren't aligned
<jamesn> MK: what it would take to fix 1.1 without making changes to definiton - if we were to keep the structure - we would need to get screen readers to support both 1.0 focusable input and also would have to look up the tree for some of the information.
<jamesn> MK: the hardest part for authors is to determine what goes on what
<jamesn> MK: what actually belongs on the input and what on the parent
<jamesn> MK: people don't understand what goes on the input and what goes onb the combo
<jamesn> MK: could be permissive and allow aria-expanded on wither
<jamesn> MK: no point to authors or screen reader or screen reader user for the wrapper
<jamesn> JD: could Narrator adapt?
<jamesn> MK: has already adapted.... hypothetical if changed something would it be more work
<scribe> scribe: joanie
Matt: Is the screen reader the problem? Is UIA the problem? Isn't UIA giving it everything?
Melanie: It is, but it's a
different structure.
... The problem is we have a declarative approach to
semantics.
... If you put the role on it, UIA puts in everything that goes
along with it.
... If you create imaginary nodes in the accessibility tree,
where do you put the properties?
Matt: Wherever UIA expects them to be.
Melanie: It seems like a weird thing to ask a browser to do.
Amelia: Are there cases where anonymous nodes get added?
Melanie: I don't know for sure,
but I don't think there are.
... I think we transparently map whatever the author has given
us.
Matt: What are potential paths
forward?
... The main problem we have right now is a lot of existing
comboboxes don't work very well.
... And they're still based on the 1.0 pattern.
Jemma: One thing to help me
understand the issue is there's a menu button. I thought it was
an easy concept to use for combobox.
... Why isn't it similar for combobox?
Melanie: I wonder if we could get more screen reader developer input on the proposal and also the 1.1 version.
Matt: And what about the naming problem?
Amelia: The 1.1 version really needs a second role, an input inside the combobox. But to also have the legacy behavior....
Matt: Maybe if we had two different roles for the different variations of comboboxes.
JN: Don't do that please.
Amelia: In your new structure without a wrapper, how do you describe widgets that thave an explicit show the list button?
Matt: That's really simple: Those
are not part of the widget.
... We actually encourage hiding it from screen readers.
Jemma: What is the resolution?
JD: (Joking) Deprecate combobox!
Matt: Actually, we could do that. An input with aria-autocomplete. (Some explanations.)
JN: And maybe fix HTML select styling.
Matt: If we could get all the
screen reader developers in a room.... This could probably be
resolved.
... We cannot require aria-controls on combobox. So it has to
be on the textbox.
JN: Why not?
Amelia: That gets back to conditional attributes.
Matt: We could put aria-controls on a textbox if it's in a combobox.
JN: We could change the definition of aria-controls....
<BGaraventa> What happens right now in UIA when aria-controls is on a textbox that includes role=combobox?
Matt: I would prefer doing it conditionally.
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/the deadline/the deadline of Oct. 24/ Succeeded: s/till ARIA 1.3/ till ARIA 1.3. The group is going with option 3./ Succeeded: s/Spec users/Spec users. Please refer the ARIA workflow documentation. https://www.w3.org/WAI/ARIA/workflow/ Succeeded: s/JN: ???/In VO your braille API accepts a string and that is then translated into the braille string/ Succeeded: s/Steers/Steer/ Succeeded: s/ASCII/a non-braille string/g Succeeded: s/\/]/ Succeeded: s/top/to/ Succeeded: s/a character/another split separation character/ Succeeded: s/note/not/ Succeeded: s/tot his/to this/ Succeeded: s/???/a spreadsheet application, you highlight a row or column as a whole for some operations. Could be implemented with a separate header/label cell, but conceptually you're focusing the row./ Succeeded: s/other/others/ Succeeded: s/with that/with invalid attributes/ Succeeded: s/???/cognisant/ Succeeded: s/these ??/these attributes/ Succeeded: s/ exceptions/ exceptions based on context, e.g. the separator role/ Succeeded: i/Table Ontology/scribe: ZoeBijl Succeeded: s/parentehical/parenthetical/ Succeeded: s/it in/grid cell in/ Succeeded: s/??/testing/ Succeeded: s/1./1.3/ Succeeded: s/??:/AK/g Succeeded: s/atttributtes/attributtes/ Succeeded: s/placeholders/posters/ Succeeded: s/ID’s/IDs/ Succeeded: s/shadow DOM, ??? & ???/shadow DOM, templates, & custom elements/ Succeeded: s/virtual scrolling/virtual content/ Succeeded: s/The idea of/On the issue of a hidden-like attribute, that's a case of speccing something that has strong use already on the web,/ Succeeded: s/In 1.0/Matt: In 1.0/ Succeeded: s/combobox because/input because/ Succeeded: s/changae/change/ Succeeded: s/button./button?/ Succeeded: s/aria-hasautocomplete/aria-autocomplete/ Present: jamesn Irfan Joanmarie_Diggs JemmaJaeunKu melanierichards Simon Pieters Bocoup Valerie Young Valerie_Young james_craig ZoeBijl AmeliaBR zcorpan Matt-King Bryan_Garaventa Found Scribe: Jemma Inferring ScribeNick: Jemma Found Scribe: ZoeBijl Inferring ScribeNick: ZoeBijl Found Scribe: melanierichards Inferring ScribeNick: melanierichards Found Scribe: ZoeBijl Inferring ScribeNick: ZoeBijl Found Scribe: ZoeBijl Inferring ScribeNick: ZoeBijl Found Scribe: jamesn Inferring ScribeNick: jamesn Found Scribe: joanie Inferring ScribeNick: joanie Found Scribe: joanie Inferring ScribeNick: joanie Scribes: Jemma, ZoeBijl, melanierichards, jamesn, joanie ScribeNicks: Jemma, ZoeBijl, melanierichards, jamesn, joanie WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth 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]