<scribe> scribe: MarkMccarthy
jamesn: 3 issues in the list,
let's start with 1028
... not sure how 1028 is different from presentational
children, can someone look?
... seems like a potential question or area for
clarification
... just need some comments
BryanGaraventa: I can take a look
melanierichards: i can probably quickly take a glance, I don't think there's much difference
jamesn: awesome, moving to
1026
... target this similar to global work that's happening, maybe
1.2 if there's time
[no objections]
jamesn: moving on to 1024
... clarifying sounds good, seems reasonable to target to
1.2
... since this is coming out of issue 999
... moving on
jamesn: only one editorial PR that can't be merged yet
jamesn: agenda for TPAC - Matt
has added a bunch of issues (awesome!)
... Carolyn put in 1021, we have a lot of combobox issues, some
planning for documentation etc. and I need to talk to other WGs
about that
... Jon added audio/video roles, waiting on some clarification
on goals
... still hoping for more items, particularly those that need
to be discussed w/ other WGs. we're running out of time for
plannign and TPAC is only a month away
... if anyone that's -not- going to be there but wants to
participate in a topic, let us know sooner than later
... we can only really offer the earlier or later sessions
(Japan time)
Bryan: won't be able to be there in person but I can dial in.
jamesn: putting a link in
<jamesn> https://github.com/w3c/aria/pull/1020
jamesn: we didn't get around to discussing this last week.. so at the top are links leading to what changed
[all reading through links]
jamesn: my question - how does
this differ from `legend`?
... we have a new method of calculating name from legend, so it
kind of seems that this is pretty mich the samething but with a
different role?
CurtBellew: is this for parity?
jamesn: yes, but what's the difference to the APIs?
Bryan: the algorithm is the same but checking for a different role
jamesn: okay, so this is still getting name from a child/descendent, so would this have much added benefit over `legend`? am I missing something?
Bryan: so these would be treated in the same way
jamesn: so... if something allows a legend to name it, shouldn't a caption? fundamentally aren't these the same?
Bryan: as far as accname goes, it's just going to ID the behavior, it doesn't care about the role
jamesn: [reading HTML mapping rules]
Bryan: is this accname spec or something else?
jamesn: no this is ARIA
spec
... question is why two roles? seems the mapping is different,
so maybe that's why.
... I am concerned about proliferation of naming mechanisms
Bryan: similar to labelling calculation
jamesn: this does seem similar. but maybe because some roles allow only one or the other, we need to account for both
Bryan: right, that's true
jamesn: okay, so they map
slightly differently. i talked myself into the importance of
this.
... do people want some time to read over and discuss next
week? we need naming stuff in -soon- or they don't make it into
1.2
Bryan: yes, I can. Jongund should be on next week too.
<pkra> +1
jamesn: I think that's true, okay so we'll punt to next week?
melanierichards: it does add complexity, but considering HTML parity, this will be important
jamesn: okay then, so we'll review and discuss with other things next week. shall we move on?
<jamesn> https://github.com/w3c/accname/issues/54
jamesn: bryan proposed some text,
do you have it available?
... [pasting text]
<jamesn> "If the root node and the current node are the same, and the current node is a widget role that supports label encapsulation, and the current node has an ancestor with role="label", then move the current node to the closest element with role="label", and return the computed name for the label."
jamesn: Bryan says this follows 2F
[group reading text]
CurtBellew: this just operates like the label tag - if it has a child, then the child uses the label's value?
Bryan: yeah
... there's only a certain list of roles that support this
feature
jamesn: it may be they're widgets, but maybe we don't specifically reference something in another spec to avoid breakage
CurtBellew: when I read it, what I get from it is what I described, so this seems like a good description
jamesn: imo, we should create a
PR that adds things like this into the 1.2 version of accname.
until we can see in context, it's hard to conceptualize
... this won't need to be merged until we're ready, so there's
no harm in creating a PR
Bryan: the tricky bit is how the accname spec is formatted.
jamesn: if you need any help, let
me, joanie, MichaelC know
... reSpec is a beast at times...
... once Bryan has a PR for that, if people could take a look
that'd be good. Bryan, when a PR is ready, send a message to
the list?
Bryan: gotcha
jamesn: moving on~
https://github.com/w3c/core-aam/issues/49
jamesn: maybe this was already discussed?
MarkMccarthy: I personally don't rember
jamesn: [reading issue]
melanierichards: I don't remember either
jamesn: straw poll - if there's a menu with a separtor, should it be split into two menus or not?
NeilSoiffer: sighted users will see one menu
harris: but there's a separator, so it's meant to be separated?
jamesn: what do native apps do?
harris: well separators group similar items in a menu
Bryan: from a computational perspective, it could get messy because browsers would have to parse how many items there are and separate them
jamesn: seems like a Firefox bug, do we need something to specify that?
Bryan: the problem with having positioning data in a menu is for a non-sighted user, they hear 1 of 2, then suddenly 1 of 5 - that's confusing
MarkMccarthy: I think that's a good reason to make it one menu
harris: +1. couldn't you use a
group to convey something similar?
... you can use groups with menuitem radios right?
jamesn: I think this is more of a
Firefox bug and we don't need spec text. but if we need that
text, let me know what it is
... I agree on what the behavior should be
MarkMccarthy: do we just have them file a bug against Firefox?
jamesn: yeah, we could. maybe we
just say the Firefox implementation is wrong and ask how we
could clarify this
... maybe joanie would know
NeilSoiffer: doesn't spec say what role=separator should be doing for AT?
Bryan: could we add a note to separator saying it shouldn't be used in this way?
jamesn: [reading separator role
text]
... maybe Firefox is doing something clever
<jamesn> https://www.w3.org/TR/core-aam-1.1/#mapping_additional_position
jamesn: the above doesn't really say anything about where things should be, or anything about separator
NeilSoiffer: something else peculiar is that the separator is focusable, which seems -really- weird
jamesn: I think this is saying
that menuitems should be processed parent-down and counted that
way
... jeez - this is [link] has wrong text anyway, then
Bryan: we could probably clarify then anyway. APG talked about separtors not being focusable and there's nothing about that
jamesn: I don't think that's why
this is wrong or why Steve asked, but there does seem to be an
issue that some spec text is incorrect
... i don't see this as a 1.2 issue, unless someone wants to do
it.
<pkra> Sorry, I have to drop off early.
jamesn: but we should file a bug
to clarify this and fix this group position stuff (section 564
of AAM) for ourselves
... i'll file that after our call
... anything else for today everyone?
harris: I made some changes to
issue 743 if anyone wants a look
... we can look at this before next week, that's fine
jamesn: i've been asking if we should remove tab or tablist, but there don't seem to be reasons -not- to
harris: want me to broaden to remove from role=tablist?
jamesn: so there's another something about aria-level some place
harris: I'll look for it!
... oh, 915, you're right
jamesn: i think consensus is to
remove it from grid
... any UI that has nested tabs should probably be redesigned,
but it's important for now in any case
... if it does happen, does aria-level help?
Bryan: makes no difference
... well, maybe helpful to some people, but it's not a huge
difference
jamesn: well maybe if you knew an application really well
CurtBellew: well is that a use case then?
jamesn: the only possible one I can think of, but it depends on AT exposing relevant info
CurtBellew: I see, okay
... the only things -I- can think of are hazy memories
jamesn: it's all hard to say because there's so few examples in the wild
Bryan: there's an example at whatsock.com/bootstrap
jamesn: if it works and does -anything- useful, it's not a problem, but perhaps not something we want to encourage
NeilSoiffer: I could imagine someone wanting to divide something into chunks, etc.
CurtBellew: Oh! I think it was
something like a customer service issue tracking thing, where
you could tab into a request then tab further into actions
etc.
... I'll do some digging
Bryan: we might be seeing more things like this in the future, where the paradigm is a page tab
CurtBellew: right, my example was a single page app, kind of like what you're describing Bryan
harris: sounds like we'll need more discussion then..
Bryan: what always seemed confusing to me is that browsers can't compute this without help
jamesn: good discussion Harris, we'll indeed need more discussion!
CurtBellew: That was Issue 743?
harris: yes, Issue 743, PR 1029
<harris> PR: https://github.com/w3c/aria/pull/1029
<harris> Issue: https://github.com/w3c/aria/issues/743
<trackbot> Created ISSUE-1054 - Https://github.com/w3c/aria/issues/743. Please complete additional details at <https://www.w3.org/WAI/ARIA/track/issues/1054/edit>.
jamesn: thanks for discussion everyone
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/not/jamesn: not/ Succeeded: s/Mozilla/Firefox/ Succeeded: s/it1/it!/ Succeeded: s/oaky/okay/ Present: jamesn MarkMccarthy pkra melanierichards CurtBellew harris BryanaGaraventa NeilSoiffer Regrets: JoanmarieDiggs MichaelCooper MattKing CarolynMacLeod IrfanAli ScottOHara JonGunderson JaninaSajka Jemma Found Scribe: MarkMccarthy Inferring ScribeNick: MarkMccarthy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 08 Aug 2019 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]