12:22:51 we also do tactile descriptions 12:23:08 no role on the description div 12:23:27 did an implementation using web components 12:23:35 provide an unobtrusive overlay as a style option 12:23:49 but this is all because the browser doesn´t do what we need 12:24:08 want programmatic access 12:24:10 q? 12:24:22 ack a 12:24:45 DIAGRAMMAR - http://diagramcenter.org/standards-and-practices/content-model.html 12:24:50 as: icon stylable by CSS 12:25:11 allows adaptation to content for various designs 12:25:24 Prototype Web Component for DIAGRAMMAR - https://github.com/mhakkinen/dg-content 12:25:38 note there is no single extended description, e.g., a photo may have one of the subject and another of the camera settings 12:25:47 David-MacDonald_ has joined #apa 12:26:03 how does AT know which one to use? 12:26:07 ack jas 12:26:37 jgw: hear that the visual cue needs to be readily recognizable, by people with various backgrounds 12:26:43 and that it shoud be unobtrusive 12:26:53 are those requirements compatible? 12:27:19 to what extent should it be stylable while remaining recognizable? 12:27:34 q+ 12:27:50 q+ to say -1 to specing UI, let s just spec a good hook 12:27:51 q+ 12:27:57 Q+ 12:28:04 ack ja 12:28:04 janina, you wanted to say it's more than just longdesc in new clothing 12:28:32 js let´s not say this is longdesc all over again 12:28:56 longdesc, though a spec and implemented, doesn´t meet all the requirements in the matrix 12:29:01 aria-details supports more of them 12:29:24 agree discussing without implementers insufficient 12:29:37 we need them to understand these use cases apply to more than just digital publishinig 12:29:52 s/publishinig/publishing/ 12:30:28 scribe: joanie 12:30:57 SteveF has joined #apa 12:30:57 JF: Jason talked about being unobtrusive. 12:31:07 q+ 12:31:09 JF: The first thing that jumped to my mind was some sort of watermark. 12:31:17 ack jf 12:31:19 JH: It's style-able. 12:31:29 JF: What does that mean for people with low vision? 12:31:52 JF: In the WCAG meting this morning, we were talking about personalization. There seems to be some commonality here. 12:32:02 JF: And it needs to be customizable per user. 12:32:09 GK: Wouldn't the AT take care of that? 12:32:16 JF: It's not just for AT users. 12:32:27 JF: Discoverability for screen readers is not a problem. 12:32:32 q? 12:32:42 JF: The problem is for sighted users who are not using a screen reader, but have other needs. 12:32:54 +q 12:32:54 JF: It seems to me that the description is being embeded in the same document. 12:32:55 Ryladog__ has joined #apa 12:33:15 Present+ Katie_Haritos-Shea 12:33:26 JF: And the piece that seems to be slipping through the cracks is external documents. 12:33:29 ack r 12:33:56 Romer: Regarding the visual cue and could it be part of the chrome, I don't think having something in the browser chrome is going to work. 12:34:13 Romer: These sorts of things do not have a good record for being implemented by user agents. 12:34:14 q? 12:34:26 Romer: It should be doable to have it handled by CSS. 12:34:40 Romer: At the end of the day, it depends on the design of the site. 12:34:57 Romer: And if it's done correctly, the end user should be able to recognize the presence of the description. 12:35:02 ack st 12:35:05 SF: I'm trying to understand the scope. 12:35:08 q+ 12:35:26 JF: We already have aria-details. And by default, it is not going to have a corresponding visual indication. 12:35:32 s/JF/SF/ 12:35:54 s/Romer/Romain/g 12:36:07 q+ to point out that aria-details over details/summary was a compromise with browsers -- aria-describedat actually fit the reqs better 12:36:14 SF: What we need to say is, "Here's the definition of a user interface control." 12:36:30 tink has joined #apa 12:36:31 SF: We need to incubate this and also get the browser vendors to participate in that discussion. 12:36:59 SF: But a better strategy would be to decide what we want this visual indicator to look like, and get it to enhance the user experience. 12:37:22 SF: The hard part is getting the user interface control implemented in the browsers. 12:37:55 SF: That's why people are looking at how to use existing functionality to accomplish what we want and need. 12:38:07 MichaelC_ has joined #apa 12:38:16 SF: Mandating what it looks like is a non-starter. 12:38:29 SF: What goes into a spec is the functionality; not the appearance. 12:38:54 SF: You can make a suggestion regarding appearance, but the way browsers implement it is the way they implement it. 12:39:12 SF: It can be unobtrusive, like the details "twisty". 12:39:35 SF: But it needs to be sufficiently perceivable and clearly interactive. 12:39:51 MH: I want to follow up on what John said. 12:40:00 scribe: MichaelC_ 12:40:10 mh: need things not to leak out of test 12:40:25 richardschwerdtfeger has joined #apa 12:40:32 our design is to have a description contained in a block and point to external source 12:40:36 richardschwerdtfeger has left #apa 12:40:48 richardschwerdtfeger has joined #apa 12:41:03 q? 12:41:08 in a web component, we would need to override default affordance with specific user´s need 12:41:27 ack mh 12:41:27 so we want to know the UI mechanism but don´t mandate the style 12:41:32 q+ 12:41:37 ack mich 12:41:37 MichaelC, you wanted to say -1 to specing UI, let s just spec a good hook 12:41:38 ack mi 12:42:36 q? 12:42:46 mc: specifying UI will cause more problems than it solves 12:43:09 need a hook and a recommendation, but not a spec 12:43:19 js: back to plugin sufficient? 12:43:45 q? 12:43:56 q+ 12:44:01 sf: with details, something can be activated via fragment link etc. 12:44:07 q? 12:44:10 jf: or could point outside 12:44:14 khs: @@ 12:44:17 ack jas 12:44:19 ack jas 12:44:36 scribe: MichaelC 12:44:47 q- 12:44:58 jgw: scripts and style sheets can pick up aria-details 12:45:09 and faster than we´d get a custom thing in HTML 12:45:10 mck has joined #apa 12:45:19 allows author styling 12:45:39 is there a new technical feature required? seems to me no 12:45:41 ack jan 12:45:41 janina, you wanted to point out that aria-details over details/summary was a compromise with browsers -- aria-describedat actually fit the reqs better 12:46:06 js: agree a mainstream argument will help in implementer discussion 12:46:20 like the discussion we had with web platform before lunch 12:46:30 we´re already compromising 12:46:50 aria-describedat arguably met the requirements better, but one implementer didn´t support 12:47:02 richardschwerdtfeger has joined #apa 12:47:03 we´re trying to find something comfortable for community as a whole 12:47:05 q? 12:47:12 jk: objection was potential to go off page 12:47:17 aria-details stays on page 12:47:27 s/jk/gk/ 12:47:35 sf: put aria-details on link? 12:47:52 could mean description of the link target 12:48:09 ack ja 12:48:37 all the interaction exists 12:48:44 js: aria-details is for disambiguation 12:49:00 sf: discovery is an author technique 12:49:00 q? 12:49:11 ac r 12:49:14 ack r 12:49:49 rs: publishers wanted visual indicator but not changing document design or script 12:49:53 therefore want css 12:50:04 agree the mechanisms exist 12:50:22 need something to activate through UI to decide whether to show the indicator 12:50:25 q? 12:50:27 via media query or something else 12:50:47 gk: that helps MathML discussion 12:50:58 could expore the media query approach 12:51:04 q+ 12:51:04 old systems wouldn´t support, but that´s ok 12:51:25 q+ 12:51:48 rs: need no script, the css can decide whether it applies 12:51:56 need to figure out how to set that media query value 12:52:01 could be done via plugin 12:52:27 gk: for books in browsers, something we´re interested in 12:52:31 as: @@ based on browser 12:52:50 ack jo 12:53:06 ack jo 12:53:18 jd: re multiple types of details 12:53:38 aria-details can only reference one element 12:54:03 gk: yeah, having multiple types is important to diagrammer work 12:54:18 allow user to pick which one 12:54:35 rs: media query for that too 12:54:37 q+ 12:54:49 q+ to speak to multiple types 12:55:11 mck: how about make aria-details reference multiple elements 12:55:15 ack ja 12:55:19 richardschwerdtfeger has joined #apa 12:55:50 jgw: display or hide based on user pref, media queries seems the obvious choice 12:56:02 like some other stuff we´ve been doing 12:56:11 how about extensible vocabulary of media queries 12:56:13 q+ 12:56:17 q+ to respond to Matt regarding the menu: If one target user group is individuals with cognitive disabilities, a menu of potentially-confusing choices seems like a bad idea. 12:56:57 ack me 12:56:57 MichaelC, you wanted to speak to multiple types 12:57:01 ack mi 12:57:32 q? 12:57:34 My point is not make aria-details reference multiple elements but instead reference a single element that is itself a menu or list. No need for multiple IDs in aria-details. 12:58:35 q+ 12:59:27 mc: @@ 12:59:40 gk: no controlled vocabulary, but human readable label 13:00:53 s/@@/don´t overload media queries, and need the types to be not a predefined list, so need way to filter on pref to show indicator, and separately on the type of indicator you want used, but how do we engineer the indicator of types? can´t overload aria-details for that part 13:01:06 rs: @@ 13:01:19 js: you might want to be able to hide all of them 13:01:30 rs: yeah, default is off 13:01:31 unless user turns it on 13:01:44 in which case they all turn on 13:02:06 js: need default presentation to be unencumbered, it´s a copyright issue 13:02:15 rd: like media queries 13:02:31 but clear not sufficient on its own for some use cases 13:02:34 ack r 13:02:52 you could decide to turn on indicators, then turn them off again 13:02:58 so user needs a way to dynamically set 13:03:37 discuss with CSS, API to set media queries 13:03:37 ack me 13:03:37 joanie, you wanted to respond to Matt regarding the menu: If one target user group is individuals with cognitive disabilities, a menu of potentially-confusing choices seems like a 13:03:40 ... bad idea. 13:03:46 q? 13:03:55 mc: massive project, good one but let´s look for other solutions short term 13:04:12 jd: we don´t want to confuse users with choices 13:04:13 Judy has joined #apa 13:04:31 if AT knows what a specific user needs 13:04:35 can personalize 13:04:38 q? 13:04:38 might need another property 13:04:48 +q 13:04:54 Judy_alt has joined #apa 13:05:10 maybe core ARIA has a starter vocabulary 13:05:11 q+ 13:05:16 that other modules could extend 13:05:31 gk: let´s not build something before it exists 13:05:37 q+ to support Joanie in that personalization is context-specific, not just user-specific 13:05:42 very small collection of examples right now 13:06:28 in US, getting to ability to access most of text content 13:06:34 but images still a problem 13:06:45 don´t think publishing industry is going to provide descriptions for all that 13:06:57 q+ to say web annotations 13:07:30 though in industries like 3d animation, there will be general interest in these descriptions 13:07:39 q? 13:07:47 ack ja 13:08:16 jgw: how about extensible vocabulary, that can be used in media queries and things that use them 13:08:22 2-level permission model, r and rw 13:08:33 user could allow some apps to set, others only to read 13:08:45 persistent storage 13:08:54 then you have the pieces for a media queries solution 13:09:39 q- 13:09:49 ack ja 13:10:08 jd: example of read vs read/write access? 13:10:23 jgw: app to configure my prefs would have rw 13:10:39 a book might just have r access to customize but not change my prefs 13:10:41 ack ma 13:10:47 ack mh 13:11:20 mh: for ETS it´s not always alternative descriptions, sometimes they daisy-chain 13:11:35 e.g., tactile version that you 3d print etcc. 13:11:50 gk: how do you decide what student gets? 13:11:55 mh: personal needs profile 13:12:08 richardschwerdtfeger has joined #apa 13:12:46 since we´re testing, we can´t increase cognitive load 13:12:58 really need clean ui model 13:13:02 ack r 13:13:09 ack ri 13:13:15 rs: media query has multiple values 13:13:19 is there a set? 13:13:21 mh: yes 13:13:35 rs: how should you set the values? 13:14:15 jgw: via permission model 13:14:23 mc: or plugin to set media query setting 13:14:40 jgw: permission model gives user flexibility 13:15:04 this is just a top-of-head proposal though 13:15:15 rs: browsers going to standardized extension model 13:15:21 if could do via plugin 13:15:36 would that work? 13:15:46 jgw: believe so 13:16:00 though user has to install the plugin 13:16:31 mc: mc this sort of plugin could get mainstreamed pretty quickly 13:16:56 rs: so let´s ask CSS for extensible media queries 13:17:24 mc: that´s a huge project 13:17:37 worth starting discussion, but let´s not predicate our solution on it 13:17:43 rd: there was an old discussion 13:18:28 jgw: think they are leaving open to extensibility 13:18:36 mc: but not sure they want to work out the actual mechanism 13:18:50 js: houdini? 13:18:52 https://css-tricks.com/developing-extensible-html-css-components/ 13:19:09 ack go 13:19:09 Gottfried, you wanted to support Joanie in that personalization is context-specific, not just user-specific 13:19:13 richardschwerdtfeger has joined #apa 13:19:14 jgw: have heard a ¨integrate if you figure out security model¨ message 13:19:30 IanPouncey has joined #apa 13:19:30 gz: think this is more complex than we think 13:19:30 not just personal preferences 13:19:33 but task context 13:19:43 equipment you´re using 13:19:46 q? 13:19:48 environment 13:19:58 q+ 13:20:06 q+ to not boil ocea yet 13:20:23 most important is user is in control 13:20:48 if interim there´s just a list of choices, maybe that´s good for now 13:21:07 risk with media queries is author makes the decision 13:21:29 gk: in MathML, publishers need to be happy with presentationn 13:22:11 maybe a media query could allow swapping what user sees 13:23:14 mc: that makes users only see certain things 13:24:50 ack me 13:24:50 MichaelC, you wanted to not boil ocea yet 13:26:16 mc: before we boil the ocean let´s make a cup of tea 13:26:25 q+ 13:28:22 mh: need this! 13:28:39 mc: sounds like we need one or 2 media queries from CSS WG (very concrete ask) 13:29:11 q? 13:29:13 tell CSS we want extensibility, not asking for yet 13:29:15 ack mi 13:29:25 and we still need to sort out the mechanism for taking advantage of this 13:29:45 rs: need extensibility of media queries because they only relate to OS features 13:29:56 mc: maybe that´s a case to end that restriction 13:30:53 mc: so we have identified new engineering, but not in ARIA 13:31:00 this meets the use cases, right? 13:31:07 js: we´re ok with plugin? 13:31:14 rs: it´s a big step forward 13:31:20 and allows innovation 13:32:20 mh: not hot on plugins 13:32:23 what will it do? 13:32:28 rs: depends what you want 13:32:39 seriously, will set media attributes based on user preferences 13:32:43 q? 13:32:49 how that is done can vary 13:33:00 q+ 13:33:17 mh: we target a wide variety of devices 13:33:37 js: with plugin, you can control its availability 13:34:13 gk: if a media query isn´t supported, it´s gonna fail 13:34:24 with the plugin, you can have better support 13:35:05 gz: chicken / egg issue 13:35:43 allow user to pick 13:37:40 Scribe: Katie Haritos-Shea 13:37:48 ScribeNick: Ryladog 13:38:13 richardschwerdtfeger has joined #apa 13:38:27 Roman: Before breakI had a question, it is infact possible to hook into the media query thing 13:38:30 SteveF has joined #apa 13:39:39 Roman: It plug-in doesnt answer the UseCase for the user that doesnt want to have a description all of the time. I amnot sure it is simpler thanhaving the non-plugin approach 13:40:43 http://browsers.about.com/od/howtousemobilebrowser1/ss/How-To-Use-Safari-Extensions-On-The-Iphone-Or-Ipod-Touch.htm 13:40:43 ??: plugin for both things? 13:41:03 RS: The plugin is for the media Queries 13:41:32 ??: What are we asking about extensibility or plugin? 13:42:01 JS:The difference may just be political - who does it 13:42:32 ??: dePub is in talks with CSS they are talking about a Media Query extension for CSS 13:42:45 JS: And we are just hearing about this now? 13:43:11 JS: Why woudnt show ARIA details not work for that? 13:44:06 RS: If you have in a plugin, you write your own media query andyou are able to write this standrardized media query, you are able to write your own 13:44:37 RS: I just posted a link, you can right a media queries to iOS 13:45:03 JS: We needto coordinate of this, if you are talkingto CSS - we need to know about it 13:46:35 JS: We are not the only ones with this kind of need. There are two sides, the tech solution, and there is the political side. One or the other W3C group for something to happen. Either WebPlatform or CSS, And it seems like CSS is going to be the easier one 13:47:15 MH: ETS is really interested in some sort of solution, this is a real need for us. If we can get this commonality 13:47:38 MH: We need a common user experience for how students address and see this 13:48:23 MH: It spans the age range, from very young kids to very adult learners. It has to work from K to elder 13:48:59 JW: I think what Rich was suggesting is a bit different what I was suggesting, but either is fine 13:49:15 JS: We just have to make this part of the agenda 13:49:42 MichaelC has joined #apa 13:49:55 GK: With this media Query for Diagrammer, the would expose the aria details 13:50:06 JS: You are writing theplugin 13:51:05 RS: You can with this icon know there is more details.. You dont have the attribute slector, you can change what type of icon and then you can show the extened description on the page or not 13:51:17 JS: Well, you turm it on 13:51:57 RS: If you had an image, lets say you want to turn on that I want to see ED. I can expose a teddy bear 13:52:21 HK: You have theteddy bear, but does the description always have to show up on the page? 13:52:56 s/Scribe: Katie Haritos-Shea/scribe: Ryladog__/ 13:53:10 RS: No. let say I decide I dont want to see ED> Then you dont see the teddy bear. In the plugin you can define how you want to see things 13:53:37 RS: Also, I have ED turned on and I want to show this x kind of thing for ED. 13:54:07 GK: Either you have a teddy bear, the publisher h the option of showing it or not 13:54:42 JW: If you had this you could implement the whole of personalizations 13:54:46 RS: Yes 13:55:09 JW: It would be good to have web applicationshave this kind of control 13:55:54 KHS:That is the long term vision we were talking with the future for Web Platform 13:56:41 RS: It takes an act of God to get this done with the browsers. With a plugin you avoid all of that 13:57:32 JS: You can do it and you can fix it in 6 months if you want. We wont get that if we try to go through web platforms and the browsers 13:57:59 GK: If you have an option to turn on teddy bears or not 13:58:26 RS: With MQ it doesnt matter what rules you have to implement 13:58:45 JS:I beleive this is emenentbly grant-able 13:59:03 RS: You just need a mechanism toimplement it 13:59:52 Roman: CSS has said that there is some way for scripts to clain support. Such as "I support MathML" 14:00:08 RS You dont wwant the page author to set that do you? 14:00:19 MH: But where is that comingfrom? 14:00:52 https://groups.google.com/d/msg/epub-working-group/jaSz8Fh9j90/Z5mMSnLIAQAJ 14:01:18 MH: How do we get that? 14:01:31 JS: I think ARIA details is it 14:02:08 JW: So I thinkfor RichProposal there would be anextension that has the authority to set the MQ flag. 14:02:25 JW: The extesion would implement the flags 14:02:41 SJ: And I think it would cover MathML and others 14:03:04 MH: I can set LV, Tactile, then it would load the other 14:03:19 SJ: ARIA details is just a container 14:03:31 RS: OK what content doI want toshow? 14:03:42 JW: Define the new MQ ame andset the value 14:04:05 RS: You could probably define what you want it toload 14:04:36 JW: I understand Rich proposal, I think it is very interesting... 14:05:23 JS: None of the browser vendors came to this meeting even though I advertised it 14:05:36 JS: We need to talk in advance 14:05:42 Coffee Break 14:06:12 JS; Thank you!, Resuming at 3:30 14:18:29 jamesn has joined #apa 14:27:13 rdeltour has joined #apa 14:28:32 Gottfried has joined #apa 14:31:46 jasonjgw has joined #apa 14:33:51 MichaelC has joined #apa 14:38:16 bob has joined #apa 14:39:01 rdeltour has left #apa 14:40:42 rrsagent, make minutes 14:40:42 I have made the request to generate http://www.w3.org/2016/09/19-apa-minutes.html janina 14:41:13 14:55:47 janina has joined #apa 14:56:09 topic: Web Payments 14:56:21 present+ Janina 14:56:23 scribe: jasonjgw 14:56:26 Chair: Janina 14:59:07 Shane: proposes to present an update on what is happening in the Web Payments activity. 15:00:01 There is a series of specifications, none of which has an explicitly defined user interface. Two of the specs have implicit user interfaces. 15:00:46 The provisions for accessibility relate to timeouts and the Web Payments WG is prpared to introduce notes addressing the accessibility issues. 15:01:15 Lisa_Seeman has joined #apa 15:01:21 q+ 15:01:49 The Web Payments API spec addresses timeouts. When the user opts to proceed with a urchase, the user interface is defined by the user agent. 15:03:22 If, during the payment process defined by the UI in the UA, the UA has to query the server for additional information, and if the query to the server is never resolved, the UI has to respond appropriately to the timeout condition - whatever "appropriately" means. 15:04:11 The Payment App spec is the second specification that addresses timeouts. 15:05:11 This spec discusses the user interface of the payment app (e.g., selection of payment methods) and there are opportunities for timeout issues there. 15:06:14 chaals has joined #apa 15:06:28 In a meeting on Thursday with Web Payments IG, a draft Web Payment User Requirements document (under development) will be discussed. 15:07:38 For accessibility purposes, the user interfaces should be as stateless as they can be and free from access barriers. 15:09:50 Katie: notes several facotrs in the design of Web Payments that need to be balanced appropriately, accessibility among them. 15:10:47 Shane argues that the system needs to be open enough to enable the needs of different users to be satisfied (by different solutions/applications). 15:11:47 Shane and Katie will also discuss the Web Payments Task Force in their meeting with the Web Payments Interest Group. 15:13:46 Lisa: success criteria have been proposed by COGA extending WCAG requirements regarding timeouts, e.g., don't lose user data in the event of a timeout. 15:14:32 Katie notes that this raises privacy issues. 15:16:53