23:55:18 RRSAgent has joined #aria 23:55:19 logging to https://www.w3.org/2019/09/15-aria-irc 23:55:30 rrsagent, meeting spans midnight 23:55:41 rrsagent, make log world 23:56:58 meeting: ARIA F2F TPAC - Day 1 23:58:03 present+ 00:02:12 Irfan has joined #aria 00:02:26 present+ 00:05:51 Jemma has joined #aria 00:07:52 mck has joined #aria 00:10:59 rrsagent, start meeting 00:10:59 I'm logging. I don't understand 'start meeting', Jemma. Try /msg RRSAgent help 00:11:10 rrsagent, start the meeting 00:11:10 I'm logging. I don't understand 'start the meeting', Jemma. Try /msg RRSAgent help 00:16:08 kzms2 has joined #aria 00:17:47 present+ Joanmarie_Diggs 00:18:07 present+ JemmaJaeunKu 00:18:44 zcorpan has joined #aria 00:18:56 spectranaut has joined #aria 00:19:01 present+ 00:19:44 AmeliaBR has joined #aria 00:20:26 present+ Simon Pieters, Bocoup 00:21:34 https://docs.google.com/spreadsheets/d/1eeq-xg0li2IKEIiyKsqhv-QOxArtbTV3m0OrG8ns-w4/edit#gid=1197832563 00:23:11 TOPIC: Introduction 00:23:50 Scribe:Jemma 00:24:40 present+ Valerie Young, Bocoup 00:25:28 present+ Valerie_Young 00:25:55 rrsagents, make minutes 00:26:24 rrsagent, make minutes 00:26:24 I have made the request to generate https://www.w3.org/2019/09/15-aria-minutes.html Jemma 00:26:36 achraf has joined #aria 00:26:52 rrsagent, make logs public 00:27:12 achraf_ has joined #aria 00:27:43 present+ james_craig 00:28:23 TOPIC:1.2 Tasks for publication 00:30:12 https://www.w3.org/2018/11/aria-charter 00:30:21 Joanie: new ARIA charter 00:30:50 https://w3c.github.io/spec-releases/milestones/?rec=2019-12-19 00:32:03 https://w3c.github.io/spec-releases/milestones/?cr=2019-11-21 00:32:10 Joanie: we have the deadline to meet, Oct 3 2019. 00:32:45 zcorpan has joined #aria 00:32:49 "Latest date to request wide review of the Working Draft Thursday, October 24 2019" 00:32:54 SONG_JAEIL has joined #aria 00:35:28 https://github.com/w3c/aria/wiki/Plans-regarding-role-parity 00:35:43 joanie: to meet the deadline we need to discuss about the scope for ARIA 1.2 00:36:43 s/the deadline/the deadline of Oct. 24 00:38:15 https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#no-consensus-yet-need-to-decide-1-2-or-1-3 00:40:36 jamescraig: we should not do password 00:41:03 from the list of "No consensus yet" 00:41:14 canvas (#927) 00:41:14 details (#928) 00:41:14 embed (#929) 00:41:14 input (type=color) (#930) 00:41:15 input (type=date) (#931) 00:41:16 input (type=datetime-local) (#932) 00:41:19 input (type=file) (#933) 00:41:21 input (type=month) (#934) 00:41:24 input (type=password) (#935) 00:41:26 input (type=time) (#936) 00:41:29 input (type=week) (#937) 00:41:31 object (#938) 00:41:34 rp (also check with i18n) (#488) 00:41:36 rt (also check with i18n) (#488) 00:41:39 ruby (also check with i18n) (#488) 00:41:41 summary (#939) 00:42:21 jamesn: aria details in the agenda later. 00:43:28 JamesCraig: aria-details with summary can be complex.. 00:44:06 cooper: I think aria-deatil is less of high priority 00:44:40 Jamesn: explaining about the concept of "generic role"... 00:45:57 q+ JamesC 00:46:28 q+ 00:47:00 q+ to suggest if you were creating a web component it could be substantially similar to equivalet HTML 00:48:10 ack JamesC 00:48:23 q+ JamesC 00:48:29 ack me 00:49:44 +q 00:50:24 present+ 00:50:42 ack MichaelC_travel 00:50:42 MichaelC_travel, you wanted to suggest if you were creating a web component it could be substantially similar to equivalet HTML 00:50:54 ack JamesC 00:51:22 jamesc: the reason for pushing role parity is in part for testing. 00:53:14 ..multiple browsers can have the same context and so that they can consistently pass the testing. 00:53:48 q+ To ask why not computed role 00:54:17 jamesc:role parity can help each browsers can have consistent result for automated testing. 00:55:42 song_jaeil_ has joined #aria 00:55:46 q? 00:56:27 song_jaeil_ has joined #aria 00:57:54 ack jemma 00:58:00 MichaelC_travel_ has joined #aria 00:59:22 I was wondering of what exact differece James and Matt have since I think you two are talking the same thing. 01:00:44 q+ 01:05:24 q- 01:05:54 ack spe 01:06:52 spe: from web dev perspective, aria should be easily matched to html. 01:09:14 spe: I was wondering when JamesN talk about the complexity of "label" what complexity he is referring to. 01:09:37 james: I was thinking about how we can make acc name calculation be easier rather than going through multiple steps of name calculation. 01:12:15 group is talking about "complexity"...according to the level of developer expereinces, or the case framework developer 01:13:35 jaemsc: Therefore, additional ways to encapusulate like Matt king mentioned may give the flexibilty to different audiences. 01:14:03 q+ 01:14:22 q+ 01:14:28 ack joa 01:14:46 q+ 01:15:58 q- 01:16:07 Joannie: by the end of this week, we may need to decide from three options, 1)forgot about this, 2) partial implementation for role mapping, 3)naming for authors need to happen so we will get the name right and etc till ARIA 1.3 01:17:51 q+ to ask if reversing referencing for labels would have implications for AT? 01:22:07 ack ir 01:25:34 Mockup for an ARIA label replica: https://codepen.io/Moiety/pen/a9d69ca0bbdadabb89828daed014203d / debug link: https://s.codepen.io/Moiety/debug/a9d69ca0bbdadabb89828daed014203d 01:26:28 ack zoe 01:26:28 ZoeBijl, you wanted to ask if reversing referencing for labels would have implications for AT? 01:28:05 Joannie: The group agrees that naming calculation should be consistent with HTML as much as it can in principle. The group needs more time for gathering naming calculation requirments. The related questions will be the detailed ARIA workflow such as implmentation, APG work, testing and more. The group will add the info to the notes for now so that we don't confuse the Spec users. 01:30:49 joannie: If there is any issue like what Irfan addressed, plese file the issue to ARIA git hub so that the group can disucss/look into the issue. 01:31:22 https://github.com/w3c/aria/issues 01:32:19 irfan: do I file the issue individually? 01:33:39 joannie: avoiding the duplicate is preferrrable. please use your judgement. also the group does triage for the issues. 01:34:07 q+ to break 01:34:21 ack me 01:34:21 jamesn, you wanted to break 01:36:32 jcraig has joined #aria 01:38:13 s/till ARIA 1.3/ till ARIA 1.3. The group is going with option 3. 01:41:21 s/Spec users/Spec users. Please refer the ARIA workflow documentation. https://www.w3.org/WAI/ARIA/workflow 01:42:51 jcraig_ has joined #aria 01:50:58 spectranaut has joined #aria 01:58:59 zcorpan has joined #aria 02:01:22 Jemma has joined #aria 02:01:31 zakim, who is here? 02:01:31 Present: jamesn, Irfan, Joanmarie_Diggs, JemmaJaeunKu, melanierichards, Simon, Pieters, Bocoup, Valerie, Young, Valerie_Young, james_craig, ZoeBijl 02:01:34 On IRC I see Jemma, zcorpan, jcraig_, jcraig, MichaelC, song_jaeil_, SONG_JAEIL, achraf_, achraf, AmeliaBR, kzms2, mck, RRSAgent, Zakim, melanierichards, github-bot, jamesn, 02:01:34 ... ZoeBijl, bigbluehat, Josh_Soref, joanie, slightlyoff, timeless, JonathanNeal, trackbot 02:02:33 spectranaut has joined #aria 02:02:42 TOPIC: aria-brailleroledescription 02:03:08 https://github.com/w3c/aria/issues/1001#issuecomment-527125274 02:03:26 Irfan has joined #aria 02:04:40 present+ 02:04:55 scribe: ZoeBijl 02:05:13 https://github.com/w3c/aria/issues/1001#issuecomment-527125274 02:05:14 https://raw.githack.com/pkra/aria/braille-props-roledesc/index.html#aria-brailleroledescription 02:05:45 JD: I put a link to the latest aria-brailleroledescription proposal 02:05:58 as you may recall during the 1.1 cycle we came up with roledescription 02:06:43 role descriptions can be pretty long 02:06:57 braille lines can be pretty short 02:07:16 if you allow authors to do something they will likely do it 02:07:43 JC: Are we proposing braille cells or strings as values? 02:07:49 JD: we’ll get into that 02:07:59 What Peter tried to do is… 02:08:11 chris_ has joined #aria 02:08:17 encourage ETS the ability to do this but discourage authors from doing this 02:08:37 I want to get a feel for, are we OK with landing this? 02:08:52 Peter has been working hard on this and ETS has use cases for this. 02:08:58 q+ 02:09:00 I will open up the floor 02:09:08 ack jcraig 02:09:17 JC: I think it makes sense 02:09:23 kurosawa has joined #aria 02:09:25 I proposed roledescription a while back 02:09:31 like “slide” comes up a lot 02:09:48 A bunch of native implementations of screen readers 02:09:51 Like voiceover 02:10:00 They pronounce Button, but print btn to braille 02:10:15 https://raw.githack.com/pkra/aria/braille-props-roledesc/index.html#example-28 02:10:19 mhakkinen has joined #aria 02:10:21 In example 28 we have “pln” to mean “planet” 02:10:44 q+ 02:11:00 What it should be is a string that is then interpreted by ?? 02:11:12 JN: ??? 02:11:20 JC: If I understand your question, yes 02:11:24 q+ 02:11:34 If we’re going to print it to the braille display we pull it through an interpreter 02:11:42 JD: I’m not disagree, trying to understand 02:11:43 ack me 02:11:53 Isn’t btn always btn? 02:12:01 JC: Braille is different in every language 02:12:11 JD: Isn’t a B always a B? 02:12:20 JC: In western languages, yes 02:12:36 But in Japanese braille it’ll probably be different 02:13:49 JD: Any author that doesn’t know which braille cells to put in probably shouldn’t put them in. 02:14:05 JC: VoiceOver has specific braille string that are shortened etc 02:14:16 For example btn for button or pln for planet 02:15:03 q- 02:15:19 Let’s say the role description is “people” 02:15:33 for grade 1 it would be printed as the entire string 02:15:43 In different grades it could be just the letter “P” 02:15:56 MK: I’m still sorta confused James 02:16:03 roledescription is like aria-label already 02:16:04 s/JN: ???/In VO your braille API accepts a string and that is then translated into the braille string/ 02:16:12 the localisation is the authors responsibility 02:16:15 q? 02:16:23 you localise roledescription you localise the label 02:16:51 I’m saying: 02:16:52 aria-brailleroledescription="⠏⠇⠝" 02:16:52 role is localised, the role names aren’t localised 02:16:58 should be: 02:17:05 aria-brailleroledescription=“pln” 02:17:24 from: https://raw.githack.com/pkra/aria/braille-props-roledesc/index.html#aria-brailleroledescription 02:18:42 q+ 02:19:28 MK: JAWS has its own abbreviations for these things 02:21:13 MK: authors should provide a legend for the abbreviation on the page 02:22:51 JC: I’m saying that the brailleroledescription value should be latin characters rather than unicode braille characters. 02:22:59 +1 to jcraig's suggestion 02:23:26 MK: Say you have the string “bl” 02:23:37 I wonder if it could somehow end up being blind 02:24:06 q+ to ask if someone can provide information on these “grades”? 02:24:58 JC: I have a colleague that’s from Germany. They use their entire system in English, except for braille, which is set to German. 02:25:33 There are only so many braille characters 02:25:55 What I’m saying is leave the translation (latin to braille) to the screen reader 02:26:03 ack joa 02:26:17 JD: I don’t know if this is the case or not 02:26:31 Is there a case where you have a task where ?? would contract braille 02:28:24 MK: I don’t understand in the proposal what is the method for communicating the dots in the string 02:28:37 JC: I can paste the rendered characters 02:29:08 JD: The intent was that the authors already know what the localisation is 02:29:25 MH: I think I’m not a fan of putting braille characters there 02:29:31 I agree with James C 02:30:11 Screen readers already handle contraction for Braille, so naively I think the description should be a long form description in the localized language. 02:30:24 q? 02:30:29 *JC demonstrates VoiceOver speaking braille* 02:30:33 ack zo 02:30:33 ZoeBijl, you wanted to ask if someone can provide information on these “grades”? 02:30:37 ack Z 02:31:36 JD: So we don’t want actual braille characters in brailleroledescription 02:31:39 Is there anything else? 02:32:18 JC: There are different kinds of braille 02:32:30 JN: That’s my recollection of why this is there 02:32:40 MK: For roledescription the issue might be a bit different 02:32:47 An explanation of braille formats. https://www.seewritehear.com/learn/an-explanation-of-braille-formats/ 02:32:47 JN: Ah then it might’ve been for aria-label 02:32:49 q+ 02:33:32 ack me 02:33:51 JD: What if we make it that authors can put in ASCII or the actual braille 02:34:30 We’re not gonna have maths in there 02:34:36 MH: Weeeeelll… 02:34:40 q+ 02:34:54 JD: Allowing authors to put in actual braille characters 02:35:14 …if they know what they’re doing 02:35:35 JC: Perhaps change the example to ASCII but still allow unicode braille input 02:35:46 Steers authors in the right direction 02:35:54 s/Steers/Steer/ 02:36:14 MK: That means that AT is required to do some preprocessing 02:36:20 to see which characters are in there 02:36:36 ack chr 02:37:31 s/ASCII/a non-braille string/g 02:39:23 https://github.com/w3c/aria/issues/765 02:39:44 Conclusion is in https://github.com/w3c/aria/issues/765 02:39:57 zakim, next item 02:39:57 I see nothing on the agenda 02:40:03 scribe: melanierichards 02:40:10 topic: Speech (James Craig issue) 02:40:47 https://github.com/w3c/aria/issues/1038 02:40:52 jcraig: there's a number of diff ways to use your voice to control devices. Dragon Naturally Speaking, Android has one in beta (I believe). MacOS, iOS, we announced voice control. Soon to be released 02:41:11 jcraig: existing support in a number of these tools to use either the rendered text, or the accessible label, to activate it. 02:41:26 jcraig: rendered text is "more", label is "more about widgets", and you can speak either 02:41:44 jcraig: any mail app usually renders the check mail button as an envelop icon 02:42:01 https://developer.apple.com/documentation/objectivec/nsobject/3197989-accessibilityuserinputlabels 02:42:03 jcraig: what we've added to public API in iOS 13 is accessibilty user input labels, label synonyms 02:42:33 jcraig: we could render 1+ optional strings. "envelope" could be one of those. Screen reader user would only hear the primary label 02:42:57 jcraig: there's API that's currently on used by voice control on iOS, but in theory could be used by [missed] keyboard access 02:43:17 jcraig: 1+ optional things that can be used in addition to label to get to the element quickly 02:43:29 jcraig: don't want users to have to memorize different labels across apps 02:43:42 jcraig: not sure if this should land in ARIA, but seems like a good group to start 02:43:50 aboxhall has joined #aria 02:43:56 jcraig: I'm not convinced ARIA because ARIA doesn't really have concept of array of strings in a content attribute 02:44:14 jcraig: that's my proposal, questions? 02:44:47 mck: if it was part of DOM, are you saying that DOM would land some stuff in the acc tree? This has to get into a11y APIs to be useful 02:45:22 jcraig: yeah, say there was a property on an element that maps into APIs...the only problem with content attribute is what are you going to use for the string splitter? single quotes? Feels awkward 02:45:44 mck: so you're not suggesting we would add a new kind of attr value, like an array, in ARIA? 02:45:45 spectranaut has joined #aria 02:45:56 jcraig: I'm not suggesting that fits into the normal DOM attr content structure 02:46:10 jcraig: closest we have is token list; space separated. But some of these may have space in the string 02:46:31 mck: sure would be nice to have maybe JSON syntax for arrays in a content attribute? 02:46:37 [nervous giggling] 02:47:04 jcraig: I can come back with a concrete suggestion? 02:47:15 jamesn: seems reasonable, not 1.2 but can be worked on in parallel 02:47:26 jcraig: I could also take it to WICG 02:47:37 jcraig: could propose as DOM rather than ARIA 02:48:00 mck: if there isn't a way to express in content, seems interesting. What would you actually propose in a PR in ARIA? 02:48:22 jcraig: IDL for extending element interface for an array of strings. But ARIA hasn't done that yet, closest is reflected attr so far 02:48:36 jamesn: can you still do it in a declarative manner that way? Probably want to do it declaratively 02:48:51 jcraig: that's why I took it here, why do you think declarative? and how would you implement in the DOM? 02:49:10 jamesn: I have a feeling authors will want to do this in a simpler method than have to add scripting 02:49:21 mck: seems like you're already doing scripting here/ 02:49:30 jamesn: [gave example of simple form button\ 02:49:35 s/\/] 02:50:06 jcraig: anyone know of precedent for overloaded attributes, define the attribute, redefine the attribute, etc in a declarative fashion? 02:50:27 q? 02:50:36 [quiet room] 02:50:53 jamesn: I'm not adversed to doing just in IDL, if it solves it for most users 02:51:05 such as foo=bar foo=baz, etc? or foo1=bar ffoo2=baz… I don’t know of precedent top that effect. 02:51:09 jamesn: solving for 90% sounds better than doing nothing 02:51:19 s/top/to/ 02:51:54 mck: if you did it in DOM, not you're for sure limiting it to scripting anyway. No advantage in ARIA unless we come up with declarative way to do it 02:52:13 jcraig: advantage is we can pull ARIA into contexts other than declarative interface 02:52:38 jcraig: could be a standalone spec as well 02:52:47 `data` attribute might be a useful precedent? 02:52:50 Jemma: an ARIA property with a token list 02:52:59 tokenlist is space separated, but some of these strings may include spaces 02:53:00 Jemma: there's one for aria-dropeffect property 02:53:13 jcraig: token list is space-separated, and these strings might include spaces 02:53:46 mck: you could use a character that you'd never include in a label, like a semicolon 02:53:49 jcraig: or a vertical bar 02:53:58 [Matt and James C agree feels messy] 02:54:10 q+ 02:54:12 mck: decision of what character you choose may have ramifications down the line 02:54:25 s/a character/another split separation character/ 02:54:28 ack ch 02:54:29 mck: maybe people go crazy for this kind of type 02:54:54 chris_: agree token list doesn't work here, there are characters that are unlikely to be spoken, but that seems special-casey to me. 02:55:56 q+ re dataset 02:56:04 chris_: if we extend this concept down, and some are space-separated, others have different separator. Spaces are an innappropriate separator. Separator chars are assuming a certain context, like a certain spoken language 02:56:25 jcraig: I suppose we could backslash our spaces but that seems dirty too 02:56:49 jcraig: in those cases where we think it's rare to be used we could use backsplash 02:56:53 [noises of dissidence] 02:57:00 ack ab 02:57:00 aboxhall, you wanted to discuss dataset 02:57:06 jcraig: open to discussion, don't think it should be a content attr 02:57:50 aboxhall: one places where we have precedence is associate arrays dataset. That's specially specced in the HTML spec, this would have to be specially specced too. Tricky 02:58:14 aboxhall: aria-labelsynonym1, -2, -3 02:58:33 Jemma: we're not ready for implementation details yet, just brainstorming? 02:58:35 jcraig: yes 02:58:39 Jemma: what's next step 02:58:48 jcraig: I'll come back with a concrete proposal 02:58:52 Link for dataset https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset 02:58:54 jcraig: Alice's suggestion is the best one so far 03:00:22 clarifying: "Alice's suggestion is the best one so far” 03:01:02 I will note be including a declaritive content attr approach in the proposal, but off the brainstorming ideas, Alice's suggestion is the best one so far 03:01:17 s/note/not/ 03:35:27 jcraig_ has joined #aria 04:00:59 kurosawa has joined #aria 04:01:34 MichaelC has joined #aria 04:02:32 mck has joined #aria 04:02:46 spectranaut has joined #aria 04:04:01 TOPIC: Table Ontology 04:04:18 "I propose a single segment on the topic of "Effects of ontology on table and grid" for discussing approaches to resolving the following 3 issues: 04:04:18 Issue #1022: (Consider prohibiting name from contents for rows in static (non-grid) tables. 04:04:18 Issue #1008: (Should aria-selected be allowed on row, columnheader, or rowheader in table? 04:04:18 Issue #79: WAI-ARIA 1.1: Cell and gridcell, which proposes depricating gridcell. 04:04:19 I don't believe we need non-WG participation. 04:04:19 I think it will take a solid hour or more to clearly layout the problems and weigh options." 04:06:19 https://github.com/w3c/aria/issues/1022 04:06:29 https://github.com/w3c/aria/issues/1008 04:06:33 https://github.com/w3c/aria/issues/79 04:06:51 ZB: Those are the relevant issues for this topic 04:07:28 Irfan has joined #aria 04:07:31 present+ 04:07:39 MK: Highlevel, there are some places in ontology where we have the same role can either be a widget or a structure 04:07:49 And some places where we have two distinct roles 04:07:56 One for the widget and one for the non widget 04:08:04 song_jaeil__ has joined #aria 04:08:11 One place where we have the same role for role and structure is row and separator 04:08:20 Normally like a row in a table is always a structure 04:08:27 A row in a grid is always a structure 04:08:33 A row in a tree grid can be both 04:08:38 Because it can be selectable 04:08:41 present+ 04:08:50 So that’s the same role for widget and structure purpose 04:08:57 Another example of this is separator 04:09:04 If it’s focusable it’s a widget 04:09:11 If it isn’t focusable it’s a structure 04:09:20 In some places we have the reverse 04:09:30 An example of that is grid cell and cell 04:09:34 If you have a cell in table 04:09:38 You use the cell role 04:09:44 but in a grid you use the grid cell role 04:09:55 So we have three issues open related tot his 04:10:01 s/tot his/to this/ 04:10:16 One is calling for the elimination of the grid cell role 04:10:19 That’s 79 04:10:28 Goes back aways… 04:10:45 1008 and 1022 are related to row 04:11:17 I can just see the writing for this “name prohibit except when…” 04:11:25 Same thing with rows being selectable 04:11:43 It’s only… I forget the properties that are on selectable 04:11:56 But there are certain states that only apply when it’s a widget 04:12:07 Not entirely sure what the best way to resolve these is 04:12:13 But in the future… ?? 04:12:28 If the row has a pattern related to selectable then it’s a selectable row 04:12:35 but the way he ontology works right now 04:12:50 if it doesn’t support selectable directly it’s inherited from somewhere 04:13:03 The way it’s related to ontology is how ?? 04:13:22 Certain states are either allowed or required and it becomes complex for both authors and validators 04:13:34 But if we were to go the path of adding more widget roles 04:13:45 q+ to say we should make it as easy as possible 04:13:57 So that summarises the issue 04:14:03 ack zoe 04:14:03 ZoeBijl, you wanted to say we should make it as easy as possible 04:14:30 ZB: earlier discussed making things easier for authors. Would different roles make it harder for authors? 04:14:46 For row for example in a table its a structure and if can focus its a widget 04:15:00 q+ 04:15:44 MK: the naming thing is interesting for row - if you allow rows to be named.... normally in a treegrid you want the name to come from contents but there are cases you want the name to come from a portion of the contents 04:16:03 if we prohibit naming on row except in treegrid - is that complicated? 04:16:15 MK: You should never make a row focusable in a grid 04:16:19 I could be wrong about that 04:16:29 JD: What if you had a message list 04:16:38 MK: Should you be using a grid? 04:16:55 I think it should probably be a tree grid 04:17:04 JD: The folder list could be tree grid 04:17:14 ABR: Another example could be ??? 04:17:34 MK: I heard of it being selected 04:17:48 But I’ve not come across an application of focusing the entire row 04:18:21 ZB: I do see people making rows focusable 04:18:31 Not sure that entirely related, just want to put that out there 04:18:46 MK: We should take a consistent approach to resolving all three of these issues 04:19:01