<scribe> scribe: MarkMcCarthy

New Issue Triage

<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

aria-relevant: find real-world use cases, consider deprecating it

<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

aria-sort recommendation to have it only on ONE header

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]

Next meetings

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.)