<scribe> scribe: MarkMcCarthy

New Issue Triage (5 mins)

jamesn: no new aria issues, one new accname, issue 43 already triaged

<jamesn> https://github.com/w3c/accname/issues/43

jamesn: looks like it's a 1.2 issue
... all caught up!

MATH agenda topics - proposal to add to first meeting of month (2 mins)

<pkra> Community Group

jamesn: there's a proposal to form a community group that has an accessibility task force

joanie: a number of those members have joined the WG as invited experts

jamesn: we would collect math topics, in order to avoid having all members come, and add them to first meeting of each month. reasonable? comments?

joanie: i want to add that, sometimes it'll be math specific, sometimes it wont
... sometimes they need other things, which might be more related to role descriptions, etc.
... people shouldn't go "ew it's math i'm not coming," it might be very relavant

<pkra> 3 weeks

jamesn: we'll do that, if there's no objections. so in three weeks' time
... there's one topic on agenda for this week though

[text separation part of role parity and next steps](https://github.com/w3c/aria/issues/699) (15 mins)

jamesn: i'd like to work out what we're going to do about the text-separation part of this issue

<jamesn> https://lists.w3.org/Archives/Public/public-aria/2019Jan/att-0027/00-part

jamesn: i'd like to get answers to carolyn's questions about how to proceed
... the link above has the questions

[discussing list items]

<jamesn> 1. We said this attribute is only for separating neighboring text content of adjacent generics. Would any other role potentially support this attribute? How about text-containing roles like paragraph? Or shall we say that the semantics of paragraph prohibits concatenating a neighboring generic's text?

mck: re item one, i think that for aria 1.2, it shouldn't be for any other roles. that's not to say we'd never use it for something else, but what we're doing isn't the absolute simplest thing to implement
... i'm seeing an increasing number of bugs in this space based on what browsers etc. are doing with styles by default
... this is tricky
... avoid unnecessary expansion of scope, testing, etc.

jamesn: other comments?
... i agree with matt, i think it'll open a big can of worms if we allow this on too many roles

<HarrisSchneiderman> +1 for expanding its usage in the future. I am in favor of not increasing scope for this large feat

jamesn: if it's awesome, in the next version we could potentially expand. but for now, limiting to one new role would be safest option

melanierichards: i agree

<bgaraventa1979> I agree with limiting roles

jamesn: disagreements? otherwise that's the decision

jg: i agree, we should limit scope as much as possible

<pkra> +1 for limiting

jamesn: decision is yes
... what if a generic is adjacent to something non-generic?

<jamesn> 2. String value: I think we need to fully spec the string value, even if we don't make it available right away (although, why wouldn't we release it with the others? It solves the $4.99 case where styling is used to represent the '.') Our initial thought was to add a string token plus a new attribute, aria-textseparationstring="string". Any further thoughts on this?

mck/jamesn: might be complicated

mck: re item 2, i fully support this but it's an expansion of scope on role parity - it's a new feature
... maybe punt it, but if it can be worked on in tandem, let's. still, may be best to separate things feature wise.

jamesn: i agree, mck
... disagreements or other thoughts?

mck: what does it actually mean to try to keep it separate; when it comes to CR time, would we write it but pull it out of draft? or...?

jamesn: i think we'd have separate PRs

jg: question on what this thing is potentially being spec'ed as? obviously it'd affect accname, description calculations, but would paragraph etc. mappings be changed?
... will this attribute be seen by a screen reader or will it only affect api calculations?

mck: only affects rendering of text modes, so invisibile like a span
... this is something that would be completely invisible to assisitve tech, in that they wouldn't say "i encountered a text separator"

jg: thanks

jamesn: the attributes are generally available to screen readers, but they shouldn't need them
... decision is that this will be spec'ed in two parts? text-separation without string, and add string later. objections?

<jamesn> Conflict resolution (i.e. when neighboring generics specify different aria-textseparation values for adjacent text):

<jamesn> For this, the plan was to specify precedence, e.g., paragraphbreak has precedence over linebreak, which has precedence over space, which has precedence over none. Does this order make sense?

<jamesn> We didn't mention the style (default) or string values. I think style (default) should have the lowest precedence, i.e. none has precedence over style. regarding string, perhaps it should have the highest precedence, i.e. it would even beat paragraphbreak?

[no objections to item 2 decision]

mck: i wrote this initial precedence order, and i think we have to define this. we'll have to work through this one by one and talk about use cases
... might be better to talk about precedence discussion after talking about item 4. reason being we'll discuss leading or trailing concepts
... and this will impact precedence

jamesn: i don't think it'll really matter?

mck: we could have a couple different high level decisions
... one could be that we don't support specifiying different ends of nodes, which i don't support.

jamesn: yeah we have to allow that

mck: if that's minimum viable product requirement, then we can talk about principles of precedence and apply them to whatever notation algorithm

jamesn: do we need an algorithm? or can we say if someone is using two separators, both go in?

mck: no, that wouldn't be doable
... let's say you're spelling "CAT" with three spans, each span containing a letter. a space to left of C and right of T, but you can't have a space near the A

jamesn: so that's space-none none-none none-space?

mck: yes
... so if you're always required to specify both ends, it could be an author error if the right end of C and left end of A conflicted, but you'd need a way to resolve it

jamesn: yes, but additive rules would end up with a space, by precedence, and result in concatenation

mck: if it was concatenation, and space and line break were present, you would worry about a trailing space?

jamesn: yeah, and if there were two spaces, it might not ultimately matter either

mck: i think that complicates defaults though
... 1) must be aware of neighbors, 2) in the default, you'd have to do extra effort to get normal results

jamesn: ok. i don't feel strongly enough to discuss much more. whoever is coming up with it can work that out. don't need a decision today.

<jamesn> ackme

mck: totally fine not making a decision today, happy to partner with carolyn on proposal for this

jamesn: if precedence is helpful, i'm happy to go with it. other opinions?

jongund: i think we need a proposal to look at with auth use cases to back it up. key is that authors have a good understanding of this attr

jamesn: yup.

<jamesn> Four: One (or two?) attributes, with one (or two?) values?

mck: we should discuss today because we've had both proposed already, and somebody has to decide what we're going to do.

jamesn: let's go to item 4 if we're not deciding on item 3

4a. One attribute, one value: aria-textseparation="token" - this was our first thought. Then we added leadingspace and trailingspace values, and it looked like we would need leading and trailing for all values... Is this a valid assumption?

jamesn: any support having single value and single token that'd apply to both ends of something?

HarrisSchneiderman: that'd be a lot of tokens to remember, so i'm more in support of 4b

mck: i'd only support 4a if we thought the others wouldn't work

jamesn: no 4a

4b. One attribute, two values: aria-textseparation="token token" - next, we looked at a token list of size 2, one for leading and one for trailing, so that we wouldn't need so many value tokens.

<jamesn> 4b. One attribute, two values: aria-textseparation="token token" - next, we looked at a token list of size 2, one for leading and one for trailing, so that we wouldn't need so many value tokens.

mck: i was assuming if only one token specified, leading and trailing the same?

james: yes

mck: parallel to css?

HarrisSchneiderman: yes, like margin
... and padding

<jamesn> 4c. Two attributes, one value each: aria-textseparationbefore="token" & aria-textseparationafter="token" (or if those names are too long, maybe aria-textbefore & aria-textafter or even aria-before & aria-after). As a developer, this method just felt "simpler" to me (potentially fewer conflicts, a bit less "awkward" than the 2-token method, etc). However, I am happy to go with the group consensus, whatever that may be.

jamesn: before discussing more, let's look at 4c

pkra: one way might be encoding order of attributes, but how does directionality fit in? right left? blocks? that's my only concern on 4b, i like 4c

mck: not sure I understand difference of 4b and 4c
... in 4b, what we're saying is leading/starting (whether LTR or RTL)... my assumption is in 4b, the first token would be same as textsepbefore, last as textsepafter. pkra?

pkra: i'd be worried 4b may be confusing if coming from RTL background

mck: gonna speculate that given the precedent set for this in CSS that unless it's been a problem there, it won't be here

pkra: reminds me of having two space separated class names with CSS. it doesn't care which is there, but that they're there
... usually attr order doesn't matter much

jamesn: some things do, but yes

pkra: even in style attr order doesn't matter (for some things)

HarrisSchneiderman: i don't think there will be much of a learning curve, but might be less efficient esp when considering mck's points
... might force devs to have more verbose markup
... simpler to have one attr, and should be less confusing for devs

<pkra> +1

<jamesn> +1 to Harris

jamesn: a quick straw poll on 4a, 4b, 4c, as opinions?

<jamesn> 4a

jamesn: or another. please vote once.

[silence]

<jamesn> 4b

<jongund> +1

<mck> +1 for 4B

<jamesn> +1

<melanierichards> +1

<pkra> +1 for 4b

+1 4b

<HarrisSchneiderman> +1

<jamesn> 4c

jamesn: 7 for 4b

[silence]

<Stefan> 4b

jamesn: 4b seems preferred. let's go with it
... anything else?

PR - ready to merge [Fix for #501 - authors MAY use ""](https://github.com/w3c/aria/pull/883) (5 mins)

<CurtBellew> +1 4b

<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/883/57567af...2f79cbb.html

jamesn: here is preview for issue 883
... sorry, that didn't work. one moment
... use github.com link in agendum title

<jamesn> https://github.com/w3c/aria/pull/883/commits/b5c237a9adf6e9d92a2be3a16df97d6067c59cf4

jamesn: comments on commit? this resolves issue 501 where validator (matt smith) mentions zero-length string not allowed, but for certain properties it should be allowed and is a validator error

mck: i think this is particularly useful for aria-activedescendent

jamesn: he wanted an authors statement to specifically allow it

mck: yeah, we have some APG statements in support. +1

jamesn: objections?

[silence]

jamesn: merging after meeting
... sorry all, our previews aren't working well right now. use the github link in the agendum title
... HarrisSchneiderman, you double checked this?

HarrisSchneiderman: not completely, but i'll do it now

jamesn: that's ok, we can now!

HarrisSchneiderman: [reading changes]

jamesn: definitely fine
... objections?
... merging after meeting

[Consider addition of property(ies) to expose braille string](https://github.com/w3c/aria/issues/765) (10 mins)

jamesn: presumably identical to agendum item 5, assuming that, any objections?

mck: let's do it

<pkra> not just ;-)

jamesn: can someone introduce?

pkra: this came out of a workshop earlier this year, in this case it was hooking into a discussion on providing separate braille representation for content
... buttons, like btn on a braille display, or equation layouts
... want to expose adequate speech layout but also the math
... we have tools that can do this, but they can't
... like desmos' graphing calculator that struggles with this
... i just wanted to start conversation about this
... nvda implemented this, their team was there

jamesn: awesome!

mck: i understand the problem, and i assume that screen readers and braille displays work similarly, off of similar abbreviation tables
... is there some other need for this not affected by role description?

pkra: the label is another case, voicing vs. tactile

mck: guess i wasn't aware there was support for different labeling

Stefan: i have to ask, i know there's a braille reader or display for jaws speech output
... suppose you have a long rolename, why can't screen readers build in to braille drivers etc. that they might scroll etc.
... i feel like we're discussing an extension of aria because of background compatibility. but why can't AT evolve?

joanie: yes. but should users have to scroll? if they like the abbreviated version...
... we might force either a lot of scrolling or helping authors give the choice

mck: here, the author is removing the ability for screen readers to provide shortened versions of roles
... i don't understand how this might work for things other than role description
... these are end user controlled, or in some cases very customizable
... nomenclature is standarized, so could abbreviations be also? should be in the hands of screen reader dev and user

joanie: talking about math, some user agents support mathml, some authors like mathml
... so screen readers might speak "the fraction 1 over two" even if text isn't there
... what about authors who use svg for instance? they have to provide what screen reader should speeak
... what you don't want is that the braille display including "the frac..." it's a niche use case but helpful

mck: so is the label used to communicate an aria-label?

pkra: yes, but not just a single label

mck: if you have the option of a spoken label and braille label... i assume there's a way using unicode etc. there's a way to use text?

pkra: devs might be happy to be lazy and shunt to AT, but...

mck: that sounds horrible

jamesn: maybe we wrap this and people who are interested can add info in the issue?

<pkra> +1

mck: seems like any attr where we want to do this, we can have the same attr name, but with -dash-braille?
... seems simple

<pkra> +1 to that :)

jamesn: theoretically, could apply to anything
... happy to see that as a proposal; not in 1.2 roadmap, but doesn't mean we can't get buy in
... useful meeting, thanks everyone!!
... pkra, can you come up w/ a proposal

pkra: yes

jamesn: coming up w/ dates for F2F, current proposal is april 30th, May 1, May 2 (tues-thurs) in san francisco

<jamesn> 30 April, 1 May, and 2 May

jamesn: this isn't definite or finalized

<pkra> bye.

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/relavent/relavant/
Succeeded: s/jamesn: i don/ jamesn: i don't think it'll really matter?/
Present: Joanmarie_Diggs MarkMcCarthy jamesn MichaelC pkra HarrisSchneiderman melanierichards aaronlev Stefan jongund Bryan_Garaventa matt_king CurtBellew
Found Scribe: MarkMcCarthy
Inferring ScribeNick: MarkMcCarthy
Found Date: 17 Jan 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.)