00:02:14 RRSAgent has joined #apa 00:02:14 logging to http://www.w3.org/2015/10/29-apa-irc 00:05:38 scribeOptions: -final 00:05:41 agenda: https://www.w3.org/WAI/PF/wiki/Meetings/TPAC2015/APA 00:05:46 chair: Janina_Sajka 00:05:51 meeting: APA FtF Day 1 00:07:17 mgylling has joined #apa 00:07:22 MarkS has joined #apa 00:07:24 Yamane has joined #apa 00:07:30 jessebeach has joined #apa 00:07:32 present: Takeshi_Kurosawa, Jason_White, Jesse_Beach, Markku_Hakkinen, Matt_King, Janina_Sajka, Michael_Cooper, Cynthia_Shelly, Léonie_Watson, John_Foliot, James_Nurthen, Joanmarie_Diggs, Mark_Sadecki, Yamane 00:07:33 mhakkinen has joined #apa 00:07:40 present+ jessebeach 00:07:59 jasonjgw has joined #apa 00:08:14 present- Yamane 00:08:24 present+ Taketoshi_Yamane 00:08:46 fantasai has joined #apa 00:08:47 present+ Takeshi_kurosawa 00:08:56 jamesn has joined #apa 00:09:05 present+ Taketoshi Yamane 00:12:56 present+ Wang_We, Can_Wang 00:13:46 JF has joined #apa 00:13:53 Present+ JF 00:14:04 scribe? 00:16:11 rrsagent, make minutes 00:16:11 I have made the request to generate http://www.w3.org/2015/10/29-apa-minutes.html jamesn 00:16:38 scribeNick: jamesn 00:16:43 TOPIC: CSS 00:16:54 JS: Need to enumerate concerns 00:17:02 JS: reading order, injected content 00:17:10 JS: Perhaps suggested a browser bug 00:17:16 JS: what else 00:17:39 MK: discussion of whether or not CSS has or should be interpreted as having any semantic meaning 00:18:25 I have noticed things if, for example, you put padding on an element. apple interprets it as space. Apple will read things as different elements if you space stuff out with padding 00:18:34 nobody else does that 00:18:37 q? 00:18:39 q+ 00:19:10 q+ 00:19:26 would need to put spaces in to do that. 00:19:44 cyns has joined #apa 00:19:46 JN: to me looks like apple is doing some sort of heuristic repair 00:19:55 ack me 00:20:50 ShaneM has joined #apa 00:21:09 zakim, agenda? 00:21:09 I see nothing on the agenda 00:22:09 JD: to follow up what MK said. The spacing could be an apple issue. related to that multiple user agents are exposing css tables to a11y apis as tables 00:22:28 liam has joined #apa 00:22:38 CS: order and position are meaningful in many cases. so i like it 00:22:49 q? 00:22:51 ack me 00:23:27 CS: w3c made a mistake seperating content from presentation assuming presentation is not meaningful 00:23:37 CS: may be a bad implementation 00:23:57 MK: presentation has meaning but it is who is repsonsible fro presenting in the a11y layer 00:24:31 q+ 00:24:34 JF: in reviewing COGA proposal. Lots has to do with content filtering 00:24:48 JF: seem display related - believe sits in the world of CSS 00:25:25 one example is an aria way of illustrating litteral and non litteral things. Ruby markup and CSS could be a way of doing that 00:25:42 JS: where css could resolve something which showed up in one of the TFs 00:25:51 JF: maybe should engage with CSS 00:26:06 JS: lets wait until the gap analysis isx put together 00:26:22 JS: waiting for them to redo docs to remove aria from it 00:26:37 JS: think we can tell CSS folks that we will need to talk to them 00:26:50 q? 00:27:08 ack ja 00:27:56 q+ JF 00:28:04 JW: still have issues around media queries. there is leftover business for media queries to specift individual needs and preferences. as well as issue regarding the kind of extensions which might be needed for coga for example 00:28:36 also have privacy issues around this 00:28:47 have a lagrge media queries issue 00:29:55 JS: have class of problems with CSS - and then a range of problems which are not problems but where we are looking for things from CSS where we would need to work jointly with them 00:30:14 JW: work underway in DPUB (joint css and dpub concern) 00:30:42 rrsagent, make log public 00:31:15 at least one known implementation of a braille stylesheet - allowing braille stylesheets development and what css support might be needed 00:31:42 coming from dpub - at that time css didn't have the grid layout necesary but i think that has changed 00:32:09 ack jf 00:32:39 00:32:46 Semantics of CSS - Layout 00:32:50 q+ to mention base font etc 00:32:52 Reading Order / Tab Order 00:33:06 Injected Content (Meta: w3c issue? ) 00:33:08 pointer to braille impl? 00:33:13 COGA Heads up 00:33:17 q+ to mention system colors 00:33:30 Media Queries - Usercontext 00:33:50 CSS Based Braille Style Sheets( ie E-Pub) 00:34:05 META: Problems, Opportunities 00:34:15 q+ to mention generated content / cssom 00:34:43 yes, but who develops it? 00:34:55 q+ JF 00:35:28 ack jf 00:36:40 q+ 00:37:00 MK: reading order / tab order. Need to get to a point so certain things happen in CSS as to what swhould happen 00:37:10 MK: need to get our team all on the same page 00:37:18 JF: we do have tools to stand firm. 00:37:22 CS: need to stop doing that 00:37:36 MK: we need to know where we stand 00:38:28 JS: 1. it remains unresolved, 2. we have added yet another spec where it is an issue 00:38:42 CS: need to look for other solutions other than the DOM needs to be in the same order 00:39:00 ack MichaelC 00:39:00 MichaelC, you wanted to mention base font etc and to mention system colors and to mention generated content / cssom 00:39:02 -> https://www.w3.org/WAI/PF/wiki/CSS CSS issues on PF wiki 00:40:01 MC: base font. system colors. desperate to see something like that come back 00:40:56 MC: connecting with user preferences 00:41:23 MC: the other one is the injected content issue 00:41:36 MK: need to figure out whose responsibility it is 00:41:42 MC: need to work on that 00:41:53 ack cyns 00:41:56 CS: on the order issues 00:42:11 CS: tables/grids etc into a11y api grid is an interesting solution 00:42:35 CS: we have an interesting problem. a fundamental feature of the architecture has a problem. 00:42:39 q+ 00:42:57 becuase of a quirk (and IMO a bug) the order in an AT is based on the DOM order 00:43:07 q+ 00:43:20 and the order of the mainstream experience is not. telling authors to ignore those features of CSS 00:43:33 +q 00:44:18 Yamane has joined #apa 00:44:19 q+ 00:44:26 q+ to identify meta-issue on semantics vs presentation 00:45:29 q+ 00:45:50 jnurthen has joined #apa 00:46:17 ack jamesn 00:49:16 JN: firefox layout engine currently does drive the order for AT - I believe that is a good behaviour. But I believe the spec says that this isn't the correct behaviour 00:49:28 need a spec change to allow this and perhaps even require 00:49:29 cyns_ has joined #apa 00:49:42 q- 00:49:52 ut also maybe need a way for an author to say the dom order is the correct order and not to do that 00:49:54 q? 00:49:58 q+ 00:50:08 q- mhakkinen 00:50:36 cs: we need to accept that the idea of authors must keep dom and layout in the same order is not going to work. we weren't effective doing this 10 years ago, and won't be now. 00:50:41 q? 00:50:48 present+ Kenny_Zhang 00:50:53 present+ fantasai 00:50:56 cs: we need to accept that the idea of authors must keep dom and layout in the same order is not going to work. we weren't effective doing this 10 years ago, and won't be now. 00:51:07 ack jessebeach 00:52:22 JB: have done some DOM order and flexbox experiments. pretty close to having support for what we are doing in browsers. seems to me that efforts to influence the behaviour of ATs might not be necessary. 00:53:13 Kenny has joined #APA 00:54:03 ack me 00:54:03 MichaelC, you wanted to identify meta-issue on semantics vs presentation 00:55:24 MC: content vs presentation seperation. That concept is difficult as authors and devs talk differently 00:55:31 MC: bigger issue than CSS 00:55:49 q+ 00:55:58 fantasai: seperation of content and style is important for maintainability and responsive designs 00:56:18 to do layout for all of these well you need media queries and to have a semantic based document. 00:56:26 MC: yet authors don't get it 00:56:49 fantasai: can't get layout to work unless my dom structure has all of this stuff in it 00:56:52 ack mck 00:57:08 jasonjgw has joined #apa 00:57:10 fantasai: so to get the things they understand (visual results) they're learning to make this distinction that we need for a11y 00:57:25 MK: so back to the FF defect which was raised and echo JN that the behaviour was good not a defect 00:58:14 MK: that should not be undone 00:58:39 MK: still have the issue of keyboard tab sequencing 00:59:02 https://bugzilla.mozilla.org/show_bug.cgi?id=812687 00:59:20 MK: I am of the opinion that keyboard order should follow layout not the dom order 00:59:23 q? 00:59:54 the notion that it is ok to jump to the left/right sidebar etc. is a problem especially for those with a low field of view 01:00:13 the relationship between keyboard sequence and reading sequence is incredibly important 01:01:14 MK: should expect the logical order to be the same as the order with touch. I beleive wcag is too forgiving - doesn't adequately descrive meaningful seqauence 01:01:26 whether flexbox or float is irrelevant 01:01:50 needs to be a way for the reading order and keyboard order to match the visual order without needing the dom to be rearranged 01:02:00 Q+ 01:02:07 hard to imagine scenarios where you override the default 01:02:31 fantasai: do users want to see the sidebar or the main content first 01:02:56 MK: the main question is what is the logical order 01:03:27 obviously some sitations where there are multiple blocks etc. but a well designed page only has a few tab stops per region 01:03:44 Q+ to note taht I18n issues may create a situation where L-to-R sequence would be R-to-L for some... 01:03:49 as you tab through the page i would argue that most of the time the left sidebar should come before 01:04:40 fantasai: often can put sidebar on the left or the right. that doesn't make a meaninful difference to a sighted user. If on the right want it to be after and if not before 01:05:32 MK: this is especially important for a screen maginifier user. If the content is in my reading order and if it moves to the right. have a banner and if the tab key jumps to the right side bar then back to the left then you have lost me 01:05:40 q? 01:06:01 ack kurosawa 01:06:12 TK: One thing we should remember is we have encoruaged usage of user stylesheets. So once CSS has semantics meaings, people who use user stylesheets can't understand the semantics. That is the bad thing. 01:07:23 TK: for DOM order etc. major browsers provide spatial navigation moving focus by pressing a nav key 01:07:36 TK: I disagree with making CSS having semantics 01:07:44 q? 01:08:08 CS: I don't think framing as CSS having semantics is the right discussion 01:08:18 jasonjgw has joined #apa 01:08:21 q+ 01:08:32 what can we do in the browser and AT layer to fix the problem 01:08:38 ack cyns 01:09:46 fantasai: if you want to navigate spatially then need to make things work for that before getting an auto layout thing to work 01:09:53 q+ 01:10:07 CS: touch screens - everything has the possibility. 01:10:35 fantasai: so many ways to reorder content that can't always fix things in 1 way 01:11:01 there are use cases for wanting the linear order to be the same as DOM order but others where not 01:11:07 picture above the heading 01:11:30 we would like for the author to put things in the right order - dont run into the keyboard order thing 01:11:52 we want the ability for the author to seperate the content order to be out of sync for the visual order they want 01:12:02 q? 01:12:16 CS: something we haven't discussed much is that there is a difference of opinion as to what is better 01:13:22 MK: disagree that the example it is better to display things in wrong order. it is an unusual layout but depriving me of information is doing me a disservice. when touch is so prevalent. 2 ways to navigate in a touch screen reader. 01:14:04 if I swipe right after the picture it would then go to the next heading not the one in the next visual order. It is a problem 01:14:19 it skipped the next paragraph 01:14:41 fantasai: mixing navigation modes. 01:14:53 MK: always switch between them. It has to be natural 01:16:28 jasonjgw has joined #apa 01:17:43 scribe: MichaelC 01:17:46 q? 01:18:11 q+ 01:18:21 js: @@ 01:18:30 cs: need user reseach 01:18:56 fantasai: @@ 01:19:01 cs: browser may need to enable both 01:19:19 mk: not asking for change of position, but information about relationship 01:20:21 +q 01:21:10 fantasai: could ask for order in either spatial or logical order 01:21:15 q+ 01:21:19 at user choice 01:21:54 jn: @@ navigating the grid 01:22:15 fantasai: you could have a grid layout with header in middle and grid surrounding it 01:22:27 you wouldn´t follow the screen order 01:22:37 jn: there are other layouts where things land wherever there is space 01:22:56 fantasai: if there is no meaningful sequence 01:23:05 jn: don´t want tab sequence to be confusing 01:24:03 ack LJWatson 01:24:11 q? 01:24:11 s/follow the screen order/follow the screen order if I told you to read me the page/ 01:24:29 ack jf 01:24:29 JF, you wanted to note taht I18n issues may create a situation where L-to-R sequence would be R-to-L for some... 01:25:13 jf: need to be flexible on LTR vs RTL 01:25:20 tk: @@ 01:25:20 ack jasonjgw 01:26:15 s/@@/HTML has dir attribute so we don't need to do that in CSS/ 01:26:27 q+ 01:26:49 liam has joined #apa 01:27:02 jgw: needing to override with tabindex is complicated 01:27:05 tk: dir doesn't affect reading order of screen reader 01:28:23 we should consider whether CSS is the place to address navigation sequence 01:28:36 ack jessebeach 01:28:58 ack jamesn 01:29:04 ack mhakkinen 01:29:12 [discussion mentioned that tabindex navigation is not great, and need an improvement to this; also mentioned flagging navigation points and possibly reordering them] 01:29:52 mh: IMS has presentations that should be well out of order from the visual layout 01:29:55 it´s non trivial 01:30:01 ack MarkS 01:30:17 ms: screen reader users all have their preferred method to navigate 01:30:31 q+ to mention screen-reading for users with reading disabilities, but who can see. Visual layout is going to be important to these users. 01:31:02 many still navigate by heading 01:31:30 can be confused if they move down from heading and wind up on content that´s not associated with it 01:31:44 js: sounds like CSS won´t solve everything 01:31:46 IMS uses term “inclusion order” which can define how “access elements … aka content blocks” are presented sequentially via read aloud tools. 01:31:53 we need to sort out what we think it should and should not 01:32:19 ack cyns_ 01:32:19 cyns_, you wanted to mention screen-reading for users with reading disabilities, but who can see. Visual layout is going to be important to these users. 01:32:36 cs: also need to consider visual users with reading disabilities 01:32:47 ms: that´s what we deal with 01:34:03 fantasai: if we could get authors to make source code order logical for reading, then re-arrange with CSS 01:34:14 you would have information about both the logical and the presentational order 01:34:23 which would make it easier to implement navigation supports 01:34:29 spatial, and sequential 01:34:45 jasonjgw has joined #apa 01:34:46 need to not shoe-horn this all into one solution 01:34:57 s/presentational/spatial/ 01:35:15 I have made the request to generate http://www.w3.org/2015/10/29-apa-minutes.html kurosawa 01:35:25 I think it's important to distinguish between spatial and presentational -- speech is also a presentation! 01:36:06 +1 01:59:36 MarkS has joined #apa 01:59:45 liam has joined #apa 01:59:46 mhakkinen has joined #apa 02:03:33 Can has joined #apa 02:03:43 What I was saying earlier is, it's been very interesting to hear from different people here about their navigation preferences. 02:03:59 I think the current architecture we have will allow UAs to provide all of these in a well-designed page. 02:04:12 Wei has joined #apa 02:04:20 And grid/flex layout will make it easier to implement 02:10:40 topic: Post break demo and discussion 02:10:46 JB shows demo 02:11:02 discussion of authors do or don´t 02:11:14 MC realizes someone should start scribing and tries to catch up 02:12:17 js: we don´t like the guidance in the css flexbox spec regarding tab order 02:12:24 Can has joined #apa 02:12:44 but CSSWG thinks it´s correct 02:12:53 mck has joined #apa 02:12:57 we need to work with them on what we both think it should say 02:13:06 mk: @@ keyboard sequence dom order? 02:13:10 cs: lower priority 02:13:14 jn: exception case 02:13:43 mk: outlaw @@ 02:14:05 @@ modify sequence 02:14:24 mk: mechanism to override default behavior 02:14:27 cs: navindex? 02:14:34 fanatasai: wasn´t supported, dropped 02:14:40 jn: @@ 02:14:42 cs: and float 02:15:08 jw: css as mechanism for determing navigation points 02:15:11 q+ 02:15:11 need to discuss how 02:15:20 cs: not sure css should determine it 02:15:33 there should be an order that reflects what´s on the screen however it got there 02:15:35 ack j 02:15:50 jn: css might think warning in spec address a11y 02:16:00 but in reality if something is possible developers will do it 02:16:30 mk: don´t want to put authors in position where they can´t use css for accessible responsive design 02:16:47 jn: but they´ll do whatever they can 02:16:55 mk: limits reasonable use of css 02:17:10 fantasai: don´t think that´s a reasonable use 02:17:14 should order the dom 02:17:44 css is about creating visual interpretations of the doc 02:17:47 the dom is the core doc 02:18:00 mk: so that means visual presentation has no meaning? 02:18:04 fantasai: that´s the goal 02:18:09 mk: but it´s not true 02:18:21 positioning tells user how things relate 02:18:28 placement has meaning 02:18:34 fantasai: placement is a way to express meaning 02:18:39 as well as color, etc 02:19:03 mk: css is the way that is expressed 02:19:55 "green" isn't the meaning, "highlighted" is the meaning, "green" is a way to express it 02:19:59 mc: we´re back to misunderstanding that semantics and presentation are mixed 02:20:16 cs: presentation implies semantic sometimes 02:20:29 mk: if css is the tool... 02:20:55 fantasai: css expresses the association using presentational output 02:21:10 but under the covers you don´t have to guess at the semantics, they´re there 02:21:54 a fully presentational approach would be sending images 02:22:03 we´re not doing that, we´re sending markup with presentation hints 02:22:05 q+ 02:23:32 we don´t want to replicate those semantics in the css layer 02:23:41 cs: there´s a gray area in between 02:23:54 e.g., position of logo is meaningful, but difficult to express in markup 02:24:37 jasonjgw has joined #apa 02:24:44 there is meaning in the presentation order of certain kinds of things 02:24:54 the separation of content and presentation doesn´t capture that 02:25:30 q+ to say the issue is that some things shouldn´t be re-ordered in order to preserve underlying meaning of semantic order 02:25:36 mk: @@ 02:25:40 ack j 02:25:48 q+ 02:25:57 jn: the algorithms are well defined 02:26:33 it´s not important that @@ 02:26:42 what´s important is that the tab order matches the visual order 02:26:45 so it makes sense 02:26:53 normally top left to bottom right 02:26:56 ack me 02:26:56 MichaelC, you wanted to say the issue is that some things shouldn´t be re-ordered in order to preserve underlying meaning of semantic order 02:27:51 q? 02:27:55 mc: think the gray area is that people don´t understand the separation of content and presentation 02:28:04 ack ja 02:28:15 therefore muck it up 02:28:55 jw: don´t want to end up with markup determining content 02:29:04 cyns has joined #apa 02:29:14 q+ 02:29:20 heuristics to correct bad authoring practices scares me 02:29:23 q+ 02:29:37 janina_ has joined #apa 02:29:39 s/markup determining content/presentation determining semantics/ 02:30:04 q+ 02:30:10 provide ways for authors to do it right 02:30:17 jn: don´t see heuristics 02:30:24 the spec is well defined 02:30:43 jw: there´s a default assumption that ltr-ttb is rational 02:30:57 author should make that decision 02:31:11 jn: author doesn´t know how content will be presented in different devicces 02:31:21 so can´t accomodate all layouts 02:31:36 would have move the dom around 02:31:42 cs: has dev and performance costs 02:31:48 ack j 02:31:51 ack c 02:32:02 cs: long history of AT heuristics 02:32:22 q+ 02:32:43 and authors just won´t do the right thing 02:32:44 jessebeach has joined #apa 02:33:20 some level of heuristics will be necessary 02:33:22 ack next 02:33:43 fantasai: there are authors who specifically want to address a11y and want a way to do it well 02:33:46 need a clear model 02:34:27 when there is a basic default style sheet you can see if your page is a mess 02:34:52 q+ to ask whether we can guide people to do the right thing, but still leave room for user agents to repair when repair is needed 02:34:55 it´s a good quick check 02:35:14 but lots of css that alters how things work makes that harder 02:35:15 ack next 02:35:27 ack mck 02:35:34 q+ 02:36:26 mk: @@ 02:36:32 cs: would like to remove ¨must not¨ 02:36:49 some behavior should be unspecified, left to UA 02:38:50 mk: not understanding how it´s simpler for author 02:39:18 fantasai: in general css shouldn´t control a11y 02:39:34 if you get into doing that, you´ve got some that does and some that doesn´t and it´s a big mess 02:39:39 to figure out what´s going on 02:39:55 people won´t choose a layout module based on its side effect on a11y 02:40:36 s/won't/shouldn't/ 02:42:55 mk: duplication of effort, author has to do what ua does 02:43:05 js: should authors have to think like that? 02:43:27 ideally css would be a magic box that allows them not to have to 02:43:32 ack j 02:43:37 ack j 02:43:37 janina_, you wanted to ask whether we can guide people to do the right thing, but still leave room for user agents to repair when repair is needed 02:43:39 q+ jason 02:44:06 I agree that encouraging people to do the right thing is a good start 02:44:23 when there is need for repair, it should be explicitly 02:44:31 mk: don´t think this is repair 02:44:35 it´s recreating logic 02:44:59 fantasai: author doesn´t need to recreate ordering in css 02:45:04 do it elsewhere 02:45:17 ack ja 02:45:51 mk: @@ 02:45:54 ack j 02:47:04 jw: author-provided dom order and tab sequence should be the sequence regardless of the layout 02:48:01 q+ 02:48:34 jw: but I can understand others might feel differently 02:48:37 mk: so we disagree on that basic point, should sort it out 02:48:46 jw: presentation should be distinct from document structure 02:49:03