<scribe> scribe: MarkMcCarthy
jamesn: two new issues
... issue 919, definitely not a 1.2 issue. if we're okay with
1.3, that's where I think it should be
... not saying we have to do it, but we can triage later
... okay, sorted.
<jamesn> https://github.com/w3c/core-aam/issues/43
jamesn: core AAM issue from Joanie. Joanie has marked this as 1.2, no need to discuss much
jamesn: F2F is coming up at the end of april, submit topics if you like, soon!
<jamesn> https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2019#Candidate_Agenda_Topics
jamesn: registration is open, link is above
<jamesn> https://www.w3.org/2002/09/wbs/83726/2019-04_FtF/
jamesn: and this is a direct
link
... 7 attending so far, we hope for more!
... filled in request for meetings in Fukuoka, Sept 16-20, have
requested to meet Thurs and Fri. other meetings will also be
happening
... great opportunity for folks who haven't been, you meet
people from several WGs
jamesn: deletion and insertion roles from last week. Matt made some comments, Aaron made modifications, Melanie made comments but don't need to block merge
melanierichards: just style things
jamesn: any other comments?
joanie: haven't looked at these, but script wants a nbsp, but for some things to get populated it needs placeholder
<jamesn> https://raw.githack.com/w3c/aria/24b545eb68ee08246b52b214af6604835d5fb019/index.html#insertion
joanie: it might look weird but should populate appropriately
jamesn: thanks for the comment though Melanie! do you want to remove comments?
melanierichards: sure!
jamesn: thanks Melanie and Matt
for reviewing
... are we ready to go?
[silence]
jamesn: no objections, so we can merge into editor's draft and log appropriate issues
<melanierichards> deleted my comments from the PR
jamesn: i'll do that following meeting or tomorrow
jamesn: thanks Melanie for doing the work on this, sorry we didn't get back to it
melanierichards: it was a teeny style request the week before CSUN, no worries. should be good to go
<jamesn> https://pr-preview.s3.amazonaws.com/melanierichards/aria/pull/895.html#time
jamesn: there's something weird... is it the formatting?
joanie: yeah, if you mean lack of css in table etc.
jamesn: maybe we need a githack link or something... there are just odd things
<pkra> https://raw.githack.com/w3c/aria/8553d266072e8f446ba296de16588b35429e723a/index.html
<pkra> is that it?
<jamesn> https://raw.githack.com/melanierichards/aria/time-role/index.html#time
jamesn: formatting still bizarre... if we can sort that out, any comments on content? if no objections, can we merge once formatting is sorted?
[silence]
melanierichards: is it possible there's something missing from the script in the diff or something?
jamesn: not important right now, if content is ok, I'm happy merging once formatting is sorted
carmacleod: i'd like a tiny
change in the note... could we say "there are -currently-
no..."
... in other words, take "time" out of the note?
melanierichards: i'll do that right now
jamesn: hearing no objections, once formatting is sorted, we can merge. if there -are- comments, please put a note in the PR
joanie: in general, notes should be consistent. i'd personally prefer keeping it the same, even though there's lots of use of "time." if we want to change one, we should change all.
carmacleod: fair
melanierichards: fair
... should we start an issue to log that style change?
or...
joanie: if people are bothered by "at the present time..." ... well it's intentially vague... I get being bothered by it though!
carmacleod: i'll let others decide
<jamesn> I am not bothered by it
MarkMcCarthy: i have no strong opinion
joanie: okay, then let's leave it. if anyone else is significantly bothered, lets log an issue
jamesn: merging once formatting is fixed. Melanie, if you have issues, ping me.
jamesn: this had some minor changes, right?
jongund: i updated the format to be more like label
<jongund> Proposed legend role definition:
<jongund> https://raw.githack.com/w3c/aria/issue-875-need-role-for-legend/index.html#legend
<jongund> Proposed accessible name calculation legend option defintion:
<jongund> https://raw.githack.com/w3c/aria/issue-875-need-role-for-legend/index.html#namecalculation
jamesn: there were some other changes since before csun, right?
jongund: there are links above
[reading through links]
jamesn: any comments on this? if there are lots, we can queue
joanie: i might wordsmith on the PR
jamesn: are we happy with concepts?
[silence]
jamesn: okay, ready to merge then!
Stefan: examples would be helpful
jamesn: for many of these, examples will come when auth guidance wrote
Stefan: but that's in a backlog, still waiting for other examples.
jamesn: workflow for 1.2 issues is that before theyr're in working draft, there needs to be guidance. sometimes that "don't do X unless ABC". We could probably do with some more detailed guidance for this
Stefan: okay, thanks
jamesn: there is a big backlog in
the APG, if you really need something, try to attend those
meetings
... APG meetings have moved to 11am PST, 2pm EST
MarkMcCarthy: as far as I know, this begins next week
Bryan: once we have examples, I can enter that into accname
jongund: to be fair, these examples should be pretty easy to write
jamesn: we can write guidance, this will give browser and AT vendors help
Stefan: yes, and examples will be helpful for -everyone-
jamesn: yep, that's the goal of the APG
jamesn: I will followup with Matt and Jemma to send APG agenda to whole mailing list
joanie: what several of us
noticed, nesting em or strong is that something is -more-
emphasized or -more- strong
... if HTML does this and we want parity, do we use aria-level?
some feedback suggested not a bad idea... we haven't gotten
much further
... Jemma doesn't like level, James doesn't like level. so, do
we use it or not?
... so, what do we do?
... one solution might be add an editrial note saying we aren't
doing anything with that, but maybe considering a new aria-
item for 1.3
jongund: ckeditor or tinymce
filter out nested em/strongs
... i'd claim we have parity - they can already do this, they
don't need a -level
joanie: jon, can you write that in the issue?
jongund: sure
jamesn: i +1'd jemma's comment, don't like aria-level. quite happy if we do nothing with it
joanie: maybe we do need to decide what we'll say about it. if we say "authors can do this" but SR ignores it... well? and if we -don't- say anything, authors might assume an SR might not like nested tags?
carmacleod: until we have a valid use case, it might not be worth discussing
Stefan: SRs and style attribute
reading, some other elements, present a challenge for Braille
and cross platform support
... was looking for some information from vendors, couldn't
find any. of course, this is a practical issue...
jamesn: question might be: does adding a role of strong create parity?
joanie: right now for IA2 and
ATK, probably for UIA, when CSS is used to format a span,
there's not a specific accessible object created. nothing to
tell SR there's something special
... so when they're putting together their construction, there
needs to be extra work done or it doesn't get presented
... kind of waiting for APG to give some help on this, as a SR
dev
s/
joanie: i'm just going to have a
user decide how they want to get the info, but this is for Orca
and Linux, so others' input would be helpful!
... I'll be good after some comments from Carolyn et al
jamesn: definition of "owned" is
not clear, is probably a better title
... this comes from an old bugzilla bug, raised again at
csun
... aria spec says an owned element is any child element (any
descendant)
... this doesn't seem to work with many things unless adding
some specific workarounds
jamesn: this has a rule, which
[reading from link]
... this diverges from WAI-ARIA's definition
<jamesn> Note: This definition is diverging from the definition of "owned element" in WAI-ARIA. The reason is that the WAI-ARIA definition was found to provide too little guidance on how to handle specific edge cases where several elements compete about the ownership, and it seem that browser implementations of this are diverging a lot. This definition seeks to find a reasonable middle ground, but will have to be updated if the WAI-ARIA definition changes.
jamesn: so, how do we want to
resolve this? do we want to change our own language to be more
specific (my vote), but let's discuss
... potentially could be a F2F topic, i think there's a lot of
issues with this
Stefan: not sure if I'm understanding... aria-owns points to ID of element that's not necessarily a child. If -owns indicates a relationship when it's not a child, is there a conflict?
Bryan: the way aria-owns is
written, it says it's not needed if it's part of the
ancestor-etc relationship
... so there's already a conflict there I think. if we say you
need aria-owns to enforce a relationship, that could cause more
confusion than it'd solve
... I don't really see why it'd be difficult to ensure that the
closest owned explicit role is mapped to its proper child, even
if there's a div or whatever between
... if you have something that's for generic, for example, it
shouldn' tmatter how many divs are in a structure, items inside
should be properly computed by browses
<Zakim> joanie, you wanted to mention that Gecko, she thinks, already changes the accessibility tree making aria-owns referenced nodes children of the owner. and to also mention the
joanie: these are things which
might not be relevant, but: Gecko already changes the
accessibility tree making aria-owns referenced nodes children
of the owner
... i wish everything did, and that might be an interesting
topic
... a side effect or consequence: authors or AT might be
thinking that -owns is the equiv of child
jamesn: what's higher on priority though?
joanie: I'd expect aria-owns making it possible for user agent implementations to find the right items
jamesn: i think browsers do that, so these things to seem to work correctly when everything is explicit
joanie: so I guess I'm voting for a) changing it but also b) that aria-owns is a direct descendent UNLESS the next item in the DOM is naturally a direct descendent
jamesn: as an author, i'd like to
be able to have intermediate divs. my compromise is that each
element between a parent and child has role of none, generic,
or presentation
... seems potentially feasible
melanierichards: the behavior
Joanie is talking about is expected in core-aam
... i'm not sure what the perf impact of all this will be,
might be a concern
<Zakim> joanie, you wanted to say she doesn't *think* it will be that hard to implement because the non/presentation children should likely be pruned
<pkra> gotta run.
joanie: not positive about this,
but: as the a11y tree is built, if it has role presentation or
none, they get pruned anyway. so as a result, the first real
child naturally is the div with row or rowgroup
... should Just Work as a result of pruning
melanierichards: you might be right
joanie: so maybe a good next step is for james to provide some markup so we can all look in various agents if everything is getting pruned and we have what we expect
<melanierichards> eems like a good idea
jamesn: yep! a number of times
i've had useless divs with role=none. the idea of allowing
generic would be to avoid that
... div role=none is weird!
... can we punt this to F2F? or back on the agenda?
[silence]
jamesn: we'll work it out! joanie will be running meeting next week,
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/... it might/joanie: it might/ Succeeded: s/hvae /have/ Succeeded: s/githack link of something/githack link or something/ Succeeded: s/dong/doing/ Succeeded: s/are moved/have moved/ WARNING: Bad s/// command: s/(did i get that right?) Succeeded: s/(did i get that right?)// Succeeded: s/ aspecific/ a specific/ Succeeded: s/(2 did i get that right?)// Succeeded: s/see you all in 2 weeks// Succeeded: s/Mealine/Melanie/ Succeeded: s/i have no strong opinion/MarkMcCarthy: i have no strong opinion/ Succeeded: s/haveissues/have issues/ Succeeded: s/(did i get that right?)// Succeeded: s/reagent, make minutes// Succeeded: s/ s/ / Succeeded: s/s// Succeeded: s/s/(did i get that right?)/ Succeeded: s/... i'm just going to have a user/joanie: i'm just going to have a user/ Succeeded: s/... no objections/jamesn: no objections/ Default Present: pkra, MarkMcCarthy, jamesn, Stefan, janina, MichaelC, carmacleod, Joanmarie_Diggs, melanierichards, jongund Present: pkra MarkMcCarthy jamesn Stefan janina MichaelC carmacleod Joanmarie_Diggs melanierichards jongund CurtBellew Regrets: IrfanAli HarrisSchneiderman AaronLeventhal Found Scribe: MarkMcCarthy Inferring ScribeNick: MarkMcCarthy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 28 Mar 2019 People with action items: 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]