<scribe> scribe: MarkMccarthy
jamesn: 1239 - if someone wants
to do a PR I'll be happy to consider
... 1.3?
sina: yeah
jamesn: 1237 - Sarah did this and opened a PR for it; MichaelC can you review?
MichaelC: yep
jamesn: PR 41 in
aria-common
... there's general agreement?
jongund: sounds good to me
jamesn: we'll rely on MichaelC reviewing, anyone else is welcome
MichaelC: i'll merge right now, seems simple enough
jamesn: i think that where this might be coming form is we didn't have a name from author section
MichaelC: looks responsive to a condition, so maybe an oversight?
jamesn: well an oversight we
didnt have until recently
... question is do we want name required on any of them?
... it's not a change to normative content, right?
MichaelC: so lets get some other folx reviewing then, I just want to make sure everyone's happy with it
matt_king: we have this guide in APG
jamesn: okay, let's not merge
this right now, I'll take a look. we might not need this
here
... 1236 - this is a 1.3 issue?
joanie: i think it's redundant and can be removed, then put into 1.2
jamesn: let's target 1.3 but if done sooner, great
<jamesn> https://github.com/w3c/aria/pull/1225
jamesn: matt, where are we?
mck: i tagged in jamesC
jamesn: he approved, we have enough approving reviews to merge. propose merging, objections?
[silence]
jamesn: merged after meeting
<jamesn> https://github.com/w3c/aria/issues/1222
jamesn: i prototyped this, came out messy. may need to be done manually regardless
sina: graphvis might be able to cluster
jamesn: maybe, anyone is welcome to do so
<pkra> jnurthen, could you share it via https://mermaid-js.github.io/mermaid-live-editor/# ? It stores the data in the URL.
MichaelC: i was doing an export/import into the UML pool and move things around manually. reimporting data meant relaying out and it became difficult
jamesn: if the graphic isn't completely optimized but usable, it should be good
sina: is there a way to get this done in 1.2?
jamesn: MichaelC, maybe a webpage or something?
MichaelC: that's what I was thinking anyway
jamesn: can we prioritize that?
MichaelC: i'm happy with that, just have to decide where it lives. assign to me
sina: happy to help with accessibility improvements
jamesn: pkra yes, soon I can
<jamesn> https://github.com/w3c/aria/issues/1214
carmacleod: this is waiting on me, I just have to answer each point etc. it's almost ready
jamesn: awesome
carmacleod: i have something going in aria-common and something into spec ref; dunno if that'll ping people to review. the links might be old until people check it
jamesn: spec ref is done quick, right?
MichaelC: depends
carmacleod: everything's already there
<carmacleod> https://github.com/tobie/specref/pull/598
MichaelC: yep I see that
one
... let's wait on specref before doing anything in our
biblio
carmacleod: for these, the only place they're defined is in specref
MichaelC: yep, let's just wait a bit on these
carmacleod: a whole bunch of
minor editorial updates, almost ready to go
... was looking at your PR jamesn, followed logic of classnames
etc., so should be right!
... i did see that AGP version names were taken out, will they
be readded visually?
jamesn: don't think we need to mention versions
carmacleod: so maybe if it could be like "See the [APG]", but the link goes to the right place, that seems better
jamesn: APG is aiming to be versionless soon anyway, so..
carmacleod: great!
Matt_King: gonna be awesome
<jamesn> https://github.com/w3c/aria/issues/1178
Matt_King: didn't get these changes done yet, hoping to this weekend
jamesn: thanks
<jamesn> https://github.com/w3c/aria/issues/1164
jamesn: made some updates on this, PR 1198 might have to change
<jamesn> https://github.com/w3c/aria/issues/1164
jamesn: made updates to that PR, if people could look and review that'd be great
Matt_King: this includes last week's changes?
jamesn: yes
Matt_King: we talked about modifying wording so it'd be good for abstract and concrete, right?
jamesn: it's not implying it's usable now
Matt_King: okay
jamesn: it lists other inheritied states and properties too, not any different right?
Matt_King: yeah, it makes sense, that's what's going to happen when non-global
jamesn: so if that closes it, we
just need reviews
... have carmacleod, scottO, and Matt_King
Matt_King: can you mark me for
re-review?
... I already did a review and requested changes
jamesn: I did that yesterday
Matt_King: ah okok, it'll be in my list
jamesn: do we have a third reviewer?
joanie: sure, I can
<jamesn> https://github.com/w3c/aria/issues/1151
jamesn: jongund was working on this, this is from wilco.
carmacleod: PR 1224
<jamesn> https://github.com/w3c/aria/issues/1151
Matt_King: this is on my unfinished todo list
<jamesn> https://github.com/w3c/aria/pull/1224
jamesn: need reviews from Matt_King, carmacleod, myself, and JamesC
Matt_King: mine's a re-review, jon put in the changes I reviewed originally...
jongund: I had a question about
this though - i used the wording "container element" but that's
not in the list of terms
... do we want the container type wording or "owning
element"?
Matt_King: i think in the cases
where "container" shows up, it's not always meaning
"owning."
... when I review I can check, but I don't think it's all that
critical
jongund: the other thing about "owning element" is that it's only used for tooltip
Matt_King: interesting
jongund: if it's only used once, is it worth having a term? maybe something to let the editors know about
jamesn: sounds like we just need reviews - let's get to this soon!
<jamesn> https://github.com/w3c/aria/issues/1150
jongund_: think I worked on that some, is there a PR?
jamesn: don't see a PR, JamesC says see 1161
<jamesn> https://github.com/w3c/aria/pull/1235
jongund_: one of the things that's unclear is can these things be owned by others; the approach I was taking was saying elements with the menu role should only own menuitem- elements, groups or separators
Matt_King: jon there is the requirement that if there's a group it has to be owned by a menu or menubar
jamesn: to me, wilco's comment stems from the confusion about direct ownership or further down the subtree; can there be intermediate roles
Matt_King: that's 1161?
jamesn: from the issue - "Reading
through the document, there seem to be cases where "owned by"
is meant to be either all descendants (as defined) but there
are other places where it is strongly implied "owned by" is a
parent/child relationship."
... seems to me that the want is for this to be tighter rather
than looser
Matt_King: i've been unclear about this too
jongund_: do we like the idea of what types of things CAN be included as descendents?
Matt_King: is this meaning
something like an intervening generic? i'm unclear as to
whether or not that's a problem
... is this referring to parent/child in a11y tree vs. DOM?
jamesn: I know i've seen problems, particularly on webkit, where it counts number of menuitems etc., generics can mess things up.
Matt_King: so mark with role=none?
jamesn: i've had to do that, yeah
Matt_King: is this a bug in browser implementation?
jamesn: yeah
aaron: for counts or in general?
jamesn: both
sina: i've ran into this many times too Matt_King
Matt_King: is this a spec problem or an implemenation problem?
aaron: sounds like both
jamesn: i'd encourage people to read wilco's proposal
<jamesn> Proposal
<jamesn> I think the simplest solution here would be to split the "owned elements" definition, into "owned children" and "owned descendants". That seems to address most of these issues. Additionally, you'd have to do something about "presentation" and "none", make it clear those elements can't "own" anything.
<jamesn> We'd also get an answer on whether or not "generic" should be included in the accessibility tree or not. Browsers don't seem to agree on that.
<jamesn> A final little bonus thing would be to make it explicit that element referenced with "aria-owns" are owned children of the first element with that attribute, and that other elements can not own them.
Matt_King: is this a 1.2 issue?
jamesn: what about 1.3?
Matt_King: i think we need to dig into this
sina: if this is fixed upstream, it would help a lot
jamesn: agree
Matt_King: YES
jamesn: but probably a 1.3
issue
... we definitely need to fix 1151, need someone to take a
look.
... someone who knows a bit about DOM4 and all that.
jamesn: I've done a PR for this, can I have some reviewers?
Matt_King: yep I'll check
joanie: i will too
jamesn: thanks you two
<jamesn> https://github.com/w3c/aria/issues/1121
jamesn: no PR for this one. assigned to carmacleod
carmacleod: yep, think it's the last one i need to do
jamesn: we'll discuss this as soon as is ready
jamesn: asking Simon if it's okay
to make this a dupe of 1178?
... i'm going to close it as a dupe of 1178 and refer
discussion there
<jamesn> https://github.com/w3c/aria/issues/1108
jamesn: this is plainly removing parenthesis, it doesn't visually look confusing. any disagreement?
Matt_King: fine w/ me, are we doing it for states and props too?
jamesn: yep I already did
... merging
<jamesn> https://github.com/w3c/aria/issues/1058
<carmacleod> https://github.com/w3c/aria-common/pull/39
jamesn: are we okay having 1.2
without this?
... moving to 1.3, reasonable?
Matt_King: i'm not sure enough about the consequences
jamesn: it might only be aaron and joanie that would have enough to comment on this right now
joanie: i'd have to get up to speed on it
aaron: email alice boxhall?
carmacleod: +1
jamesn: i'll get emails off and CC joanie, that might work the remainder of our issues today
carmacleod: good idea
jamesn: i wonder if it's useful, and if it's not, is it helpful?
carmacleod: it was one of the
comments in 1100 so here we are
... wanted to make sure to clarify that things can be focusable
by script or user
Matt_King: problem we're trying to resolve is including or excluding elements from a11y tree
sina: this is a general parent focusable situation?
carmacleod: yep
Matt_King: is input focus the right term? like the same or similar in DOM spec?
jamesn: we need to make sure our usage of focusable here doesn't conflict with anything else explicit in our docs
sina: this definition is a superset of those other definitions. this doesn't -harm- those other definitions
jamesn: as long as it doesn't cause harm
sina: well in one sense, it could cause harm if "focusable" means "to be tabbed to."
Matt_King: might need a term "user focusable" vs "focusable"
jamesn: don't need to do that now
aaron: i differentiate with "focusable" and "tabbable"
<pkra> gotta go. bye!
Matt_King: the text jamesn just read had that differentiation
jamesn: so, if a seperator with tabindex=-1, is it then focusable? it is right?
Matt_King: yes
jamesn: as long as we're clear. so, for reviewers, i'd like someone to go through the 59 instances of "focusable" and make sure it's not contradicted
carmacleod: i did do that but would appreciate a bigger look. didn't see anything
sina: this doesn't -weaken- the requirement jamesn read right?
jamesn: i don't think so
Matt_King: it'd weaken it in the
sense if it was tabbable it'd be considered focusable
... what jamesn read was informative not normative.
jamesn: but it -was- a normative
section
... it's a SHOULD
sina: afraid that it'll cause some folx to do the minimum with -just- tabindex=-1 and move on
jamesn: add a review - if something sounds wrong it might need fixing
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/[who else?]/JamesC/ Present: jamesn Joanmarie_Diggs MarkMccarthy MichaelC pkra StefanSchnabel Matt_King carmacleod Regrets: BryanGaraventa HarrisSchneiderman CurtBellew Found Scribe: MarkMccarthy Inferring ScribeNick: MarkMccarthy 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]