<scribe> scribe: MarkMcCarthy
<joanie> https://github.com/w3c/aria/issues/849
jn: is issue #849 in conflict, if we say there's an implicit value and the role doesn't have it?
any opinions? close it? there's already a +1
carmacleod: i think they're trying to write a tool, so they need it to be clear if aria-atomic is true
jamesn: if I was replying, i'd
say it's not an issue - implicitly true
... if noone else wants to take it, i will. it's for 1.2
milestone
joanie: another instance of required vs supported, what the implicit default is
jamesn: this isn't required, right?
joanie: yes, and i don't think it's in conflict. but i'm saying on a meta level, supported vs required, implicit values are confusing
jamesn: let's not dive into resolution; anywhere there are implicit values, if there's a default that's not set, make a note
mck: i think some language to the
effect of jamesn's comment that goes in aria-atomic prose would
resolve issue
... i think this is reasonable
jamesn: i suppose specifying some things have other things set might be useful
mck: unless a specific role defined has an explict default, the implicit value is false
jamesn: do you want this matt?
mck: yeah that's fine
jamesn: next issue #845, 1.2 carolyn?
carmacleod: yeah i think so. i typed in the issue what we'll probably use to fix it. if anyone could read through that'd be great
jamesn: we've also got #843, but
i've merged it already
... aacname, no issues. coreaam, skipping that issue for
now
... moving on to aria issues w/ no milestone, let's spend about
10min
<jamesn> https://github.com/w3c/aria/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone+sort%3Acreated-asc
jamesn: query is here, first #72
carmacleod: that's weird to have
a text field in a live region (about issue #72)
... strange use case
jamesn: where do we put it?
carmacleod: i want to say you're not allowed to have text fields in live regions
jamesn: yes, so what
milestone?
... may have times where it's user modifiable etc. but not
necessarily common. let's move to 1.3?
carmacleod: okay, but it might just be a single sentence, or we can add something like "unless..."
jamesn: am i hearing that we should take this on now?
mck: no, i agree with jamesn's
initial sentiment.
... not urgent
... easily resolved
jamesn: let's move it to 1.3
carmacleod: +1
mck: +1
jamesn: #74 fits into role parity somewhere, right? 1.2 issue?
mck: makes sense to me
jamesn: 1.2 it is
... #76, a technical problem. doesn't sound like an aria
issue...?
joanie: since we split the repo, is this common tools?
jamesn: aria-common? michael?
<joanie> https://github.com/w3c/aria/issues/76
jamesn: or just close?
MichaelC: i think it should be moved to aria-common, i thought this was dealt with though
jamesn: i'll deal with it later,
put it in the comment it was moved
... #83, do we still have these aria-roledescription issues?
matt thought it was a 1.1. issue. ... looking at examples
... the ones matt thought were problematic are still
present
<jamesn> https://github.com/w3c/aria/issues/83
jamesn: sounds like it's as
simple as removing things. matt said it should 1.1, so move to
1.2?
... moving to 1.2. sounds relatively simple
... is that okay?
[silence]
jamesn: no objections then.
<jamesn> https://github.com/w3c/aria/issues/275
jamesn: issue #275, we can
probably close this
... disagreements?
carmacleod: I'd have to read stevefaulkner's OG draft
jamesn: the fact it's 2 yrs old and no more comments, it's probably overcome
carmacleod: this "article" isn't a landmark right?
mck: correct
... article is getting mapped to article
carmacleod: that's great!
... not a landmark, not a region
mck: yes
jamesn: close?
mck: yes
carmacleod: it's resolved itself
jamesn: thanks! moving on
<jamesn> https://github.com/w3c/aria/issues/712
jamesn: #712, aria-relavant.
aaron thinks aria-relavant hasn't been helpful and hasn't found
good use cases
... asked for real world use cases
... could people read through and give thoughts?
mck: first reaction is difference
between removals and not including removals, that's the one
thing i think had support and good potential
... can't actually think of an application i've used that i've
experienced this with
... thought we tried this with a chat app at IBM
carmacleod: i can try it if it's still here
mck: would've probably been web
based chat
... oh not chat! sametime meetings
... something in that application... a list of people in the
meeting?
... maybe this doesn't make sense either, because it told you
they left, so maybe it was a live-region...
jamesn: the only time i've tried
to use removals, what it spoke wasn't really useful to know
what was going on
... hard to know what the keyword is; messaging found to be
better
mck: +1. in practice, maybe we did do something different. we controlled the message spoken
jamesn: rathr than AT putting in effort to make aria-relavant work, i'd rather they put in effort to make messaging easier
mck: also more robust support for whether or not it's polite vs assertive
jamesn: so, i'm just gonna leave
this out here for people to add thoughts. we're going to
consider depricating aria-relavant
... need to find real world use cases where this is good or
best way to do something, not sure we have
carmacleod: bryanG had a test case that works with JAWS
Bryan: which test case?
... it's in firefox, which is the only place it actually
works
jamesn: if it's only supported in FF, is it useful? oh also works in IE11 w/ jaws18
mck: nobody in the real world
will rely on this feature with those combos (JAWS and IE, JAWS
and FF)
... who's going to have a market that narrow?
bryan: not just jaws in firefox, also nvda in firefox. usage scenarios might be different, not sure how widely it's used
mck: aaron trying to decide if chrome should support?
jamesn: seems that way
mck: starting to agree w/ that. if you take away removals from this, there's really no meat left for aria-relavant
bryan: another issue: there's a note that says aria-relavant is optional for AT to implement, which meant it'd be spotty anyway
jamesn: i'd like everyone to
think about use cases, if you can, please put them in the
issue. that's a good reason against deprication
... if we can't, then let's consider deprication
... going to mark this as 1.2?
carmacleod: no. as it's attribute related
jamesn: ok, 1.3. doesn't mean we can't work on it or depricate sooner. just doesn't fit core 1.2
mck: this is similar to drag and
drop; when we depricated that we addressed the definition of
deprication... so if it's depricated in 1.2, we're just
removing tests from PR
... so doing it in 1.2 is a really small task. if we're going
to depricate, sooner is better.
jamesn: full +1, but we need to
come up with use cases and think on it
... happy to put on agenda again later, if there's activity
mck: ok. so rather than just us, maybe go to broader community? WAI-AG, webaim? is anyone relying on this?
jamesn: +1, who should take on? Aaron?
mck: yeah exactly, he's a good candidate
jamesn: i'll email aaron
jamesn: this is something else
that's not strictly 1.2
... had some activity so let's discuss
... david stated that aria-sort could sort multiple columns
<joanie> https://github.com/w3c/aria/issues/582
jamesn: but this doesn't solve
the problem. joanie and i were disscussing, came up w/ skeleton
proposal
... something like aria-sortedcolumns or something, applied at
grid or table level, point to IDs
... could still have aria-sort asc, desc on column level
mck: yeah, i think we need something like sort precedence
jamesn: right, that's what i meant
carmacleod: the last comment offers aria-sort-order, based in column order rather than ID. might be better for authors
mck: then you'd have to do checking to make sure col index matches, etc.
carmacleod: right
mck: another way is to just put
it on the actual column
... then the only checking is for sort-precedence
jamesn: the reason i like it
onthe grid/table level is that i think the most useful way of
exposing if it's sorted is if they navigate w/ AT it could
indicate how it's sorted immediately
... rather than working down the tree
mck: true, more work for AT, but likely less error prone for authors, easier to implement in browsers, and AT are still going to have to bubble down
jamesn: i don't know if you need
to, but maybe. could still indicate on the column, but wouldn't
habe to expose order
... some framework will be doing that, so making it easy on an
author... not sure people will be hand coding the sort
mck: yeah, that's true
carmacleod: something web components has to think about
mck: it'll be interesting to see
how it goes
... where do we place most of the burden? better to make easier
for authors? AT/browsers only do once
carmacleod: i agree, from a dev
POV
... in this case, i'd rather something on the column rather
than the table
jongund: i agree, authoring should be primary consideration
jamesn: concern about putting it on columns: we need to write "AT Should expose at X level"
jongund: don't screen readers already have to do a lot to figure out the table?
jamesn: yeah, but they don't expose sort
mck: but jongund is right, they have to walk through the table...
joanie: the table interface
jongund: and they could pick it up off the table header
mck: might be more work for browsers
joanie: platform accessibility APIs might make it easier, but if it's not added it'll be exposed another way. not a blocker
jamesn: everyone wants it at the
column level? i can live with that
... marked as 1.3
carmacleod: agreed
jamesn: could be worked on a little at a time if folks interested. anything else?
[silence]
jamesn: assuming this is okay
with everyone, meet on 12/6, 12/13, ... 12/20....?
... objections to 12/20?
<joanie> I am not available on the 20th
mck: that's my first day of vaca
jamesn: we won't meet on 12/20,
12/27
... start on 1/3
... i'll try to get agenda out in time for that
mck: seems reasonable
jamesn: might go out late on
2nd
... ok! thanks everyone, good discussion. we'll try and get
back on 1.2 grind, role parity, etc.
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) Present: jamesn MarkMcCarthy MichaelC Joanmarie_Diggs jemma carmacleod jongund Regrets: MelanieRichards JaninaSajka PeterKrautzberger StefanSchnabel Found Scribe: MarkMcCarthy Inferring ScribeNick: MarkMcCarthy Found Date: 29 Nov 2018 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]