12:28:42 RRSAgent has joined #eo 12:28:42 logging to http://www.w3.org/2014/08/29-eo-irc 12:28:44 RRSAgent, make logs world 12:28:44 Zakim has joined #eo 12:28:46 Zakim, this will be 3694 12:28:46 ok, trackbot; I see WAI_EOWG()8:30AM scheduled to start in 2 minutes 12:28:47 Meeting: Education and Outreach Working Group Teleconference 12:28:47 AnnaBelle has joined #eo 12:28:47 Date: 29 August 2014 12:29:19 WAI_EOWG()8:30AM has now started 12:29:26 +AnnaBelle 12:29:47 +Shawn 12:29:51 +??P2 12:30:00 +Howard 12:30:01 zakim, ??P2 is me 12:30:01 +kevin; got it 12:30:16 Howard has joined #eo 12:30:17 zakim, call EricE-Skype 12:30:17 ok, yatil; the call is being made 12:30:19 +EricE 12:30:19 zakim, call shadi-617 12:30:19 ok, shadi; the call is being made 12:30:20 +Shadi 12:30:30 zakim, nick yatil is EricE 12:30:30 ok, yatil, I now associate you with EricE 12:30:32 zakim, mute me 12:30:32 EricE should now be muted 12:30:36 zakim, mute me 12:30:36 Howard should now be muted 12:30:58 Sharron has joined #eo 12:31:12 trackbot, start meeting 12:31:14 RRSAgent, make logs world 12:31:15 zakim, call bim-617 12:31:15 ok, Bim; the call is being made 12:31:16 Zakim, this will be 3694 12:31:17 Meeting: Education and Outreach Working Group Teleconference 12:31:17 Date: 29 August 2014 12:31:17 ok, trackbot; I see WAI_EOWG()8:30AM scheduled to start now 12:31:26 Chair: Shawn 12:31:28 zakim, who is on the phone? 12:31:28 I notice WAI_EOWG()8:30AM has restarted 12:31:30 On the phone I see AnnaBelle, Shawn, kevin, Howard (muted), EricE (muted), Shadi, Bim 12:31:36 Scribe: Sharron 12:31:47 +??P5 12:31:57 zakim, mute me 12:31:57 Bim should now be muted 12:31:59 zakim, ??P5 is me 12:31:59 +Andrew; got it 12:32:54 Topic: Implementing Accessibility 12:33:00 +Sharron 12:33:07 http://w3c.github.io/wai-planning-and-implementation/Overview.html 12:33:54 paulschantz has joined #eo 12:34:12 Topic: Implementation Plann 12:34:27 s/Plann/Plan 12:34:30 +PaulSchantz 12:35:06 +Jan 12:35:21 +metzessive 12:35:37 metzessive has joined #eo 12:35:58 e-mail comment from Shawn: http://lists.w3.org/Archives/Public/w3c-wai-eo/2014JulSep/0053.html 12:36:06 Wayne has joined #eo 12:36:13 Shadi: From email, sometimes the Key Actions are less clear and the relationship within the Details section is not clear as to which Key Action is under consideration. So the suggestion is to have the KeyActions become expandable so it is clear. 12:36:19 Shawn: It was an idea 12:36:37 Shadi: It was a great one, but will take some significant rewriting. 12:37:02 ...first it will make the Key Points clearer and then it will make the relationship direct. 12:37:04 +Wayne_Dick 12:37:11 Kevin: Sounds great to me. 12:37:40 Shadi: What was the reaction of the group? 12:37:53 +1 to Shawn's idea 12:38:09 Sharron: skeptical... 12:38:21 Sharron: My first reaction is that this is too linear of a treatment, things are too interrelated 12:38:23 does this mean folding "more detail" section into key actions section? 12:38:29 +1 to Sharron's opposition 12:38:30 Wilco has joined #eo 12:40:04 Kevin: I think there is the potential for that but I do like the idea that there is a direct way to look at the detail for each action. When looking at the content, there are some that would have no expanded content. In some there are Key Actions that are so broad that they would be difficult to synopsize in that way. 12:40:11 [ Paul - kinda. the key actions would be expandable to have more detail under each.] 12:40:15 Shadi: Do you ahve an example? 12:40:22 q+ 12:40:27 s/ahve/have 12:40:29 q+ to say might also make it harder to skim 12:40:31 zakim, nick mezzessive is Jan 12:40:31 sorry, yatil, I do not see 'mezzessive' on this channel 12:40:33 zakim, who is making noise? 12:40:41 zakim, nick metzessive is Jan 12:40:41 ok, yatil, I now associate metzessive with Jan 12:40:44 shawn, listening for 11 seconds I heard sound from the following: kevin (73%), Shawn (4%), Andrew (4%), Sharron (8%) 12:40:49 http://w3c.github.io/wai-planning-and-implementation/Overview.html#resp 12:40:53 zakim, mute me 12:40:53 Shawn should now be muted 12:40:55 q? 12:41:45 zakim, nick metzessive is Jon 12:41:45 sorry, shawn, I do not see a party named 'Jon' 12:42:05 zakim, Jan is Jon 12:42:05 +Jon; got it 12:42:15 Kevin: Under Roles and responsibilitites the discussion of that could be huge...perhaps it indicates we should bring that into smaller actions. Another under "gather support" has promote awareness...there is not much more to say about that. 12:42:22 ...one example only. 12:42:48 ack p 12:42:51 ack paulschantz 12:42:55 Shadi: If we adopt that approach we would need to make that consideration. 12:43:10 q+ 12:45:08 Paul: This will reduce the skimmability considerably. But if we did that, we could then add even more detail beneath. The very first paragraph provided a friendlier, more conversational approach. As it is now it is a Project Plan. I have always thought there should be more detail in the Key Actions. 12:46:14 Shadi: You are assuming that Key Actions would still be expanadable, yes or no? 12:46:19 Paul: Yes 12:46:53 Paul: So I support it. If you want more detail for one point, you have to expand the whole More detail - but the more detail is really not that much. 12:46:55 ack me 12:47:06 ...so that if you are interested in the detail of one point, you must expand the entire section. You don't get that much more detail for each of the Key Actions 12:47:51 Paul: So when you expand the section it very closely follows the sequence of the Key Points about it. 12:48:10 Shadi: It does not in fact in all cases. But maybe you are saying that they should. 12:48:15 not such a close match in other sections 12:48:37 ack me 12:48:37 Andrew, you wanted to say might also make it harder to skim 12:49:17 q+ 12:50:04 Andrew: I find that short, sharp and to the point makes the material uite nicely skimmable. The paragraphs match reasonably well at first but later on the discussion, such as in Roles... are more broad and interrealeted. We will have to restructure the bullets as well as the text. 12:50:05 ack me 12:51:14 maybe we highlight some key words in the 'more detail' discussion? 12:51:58 Shawn: I realize that the email got sent at the last minute. I found that I woudl read a couple of bullets, if there was one I didn't quite understand, I was distracted trying to find the detail of the point I was looking for within the text. So then I would find myself not wanting to look for explanation so just reading along and not finding the detail. There is also a lot of repetition. That is 12:51:58 what I was trying to address. 12:52:02 zakim, who is noisy? 12:52:10 document structure might not match usage 12:52:22 shadi, listening for 10 seconds I heard sound from the following: Shawn (76%) 12:53:11 ...it seems like the headings (Now Key Actions) would be easier to skim. so even if we leave it in this format, we need to be able to tie the discussion more closely to the Key Actions. The broader topics may need to be introduced differently. 12:54:02 q+ to talk about the purpose of the key actions and more details section 12:54:36 Shadi: One of the discussions on the table was to make the order of points within the More Details more closely mirror the order of Key Points. It would have to begin with a similar phrase and then what is the point? 12:55:08 ack kev 12:55:08 kevin, you wanted to talk about the purpose of the key actions and more details section 12:55:08 s/Shadi/Shawn 12:55:26 s/Shawn/Shadi 12:56:24 Kevin: One of the thoughts is to review the purpose of the current structure. Key Points were meant to be a quick overview of what needs to be done. The More Details is meant to give people specifics about what to do to achieve the Action. 12:56:34 [ /me likes the clarification of "why" and "how"] 12:57:07 q+ 12:57:23 http://w3c.github.io/wcag-em-report-tool/dist/#/audit/test 12:58:07 ...an expand capability. It seems what we are suggesting here with all the expand features would be a challenging read. So mperhaps an arrow expand collapse would minimize the distraction. 12:58:32 ...we need a "Why and How" within each section. 12:59:13 Shadi: How does that help? If you come across a Key Action and you don't understand... 12:59:16 [ /me also agrees for ex-col on key actions AND also a general section ] 12:59:26 Kevin: You would have a mix of both. 13:00:06 +1 to Shadi's summary 13:00:16 s/mperhaps/perhaps/ 13:00:20 ack w 13:00:21 sounds like applying the old Lotus Notes 'twisties' as he bullets 13:00:21 Shadi: So the Key Action would be expandable to find out a little bit more. And for things that are broader, we could place the further details in another section either before or after 13:03:02 Wayne: I kind of see 3 things...How, Why and What. The Key Actions are kind of iconic. The use case is someone is trying to make a plan, will read through this and then know what to do. To give people more information about just what this bullet actually means is improtant. There needs to be a correspondence between what it is , why it's improtant, and how to achieve it. We probably also need a 13:03:02 summary narrative, pulling it all together. Having the expand feature right there is improtant. Also correlated paragraphs within is important but also needs a synthesis. 13:03:20 zakim, who is on the phone? 13:03:20 On the phone I see AnnaBelle, Shawn, kevin, Howard (muted), EricE (muted), Shadi, Bim (muted), Andrew, Sharron, PaulSchantz, Jon, metzessive, Wayne_Dick 13:03:28 zaki, mute me 13:03:33 zakim, mute me 13:03:33 Shawn should now be muted 13:04:16 Shadi: We will have short additions to each of the Key Action, specific to the Key Action that can expand. There will still be a narrative to inlcude Why and How that tie it all together as introduction or concluding narrative. 13:04:24 Shawn: That addresses my concern 13:04:37 Andrew: Yes, I suspect so. 13:05:09 Shadi: It looks like we can try this and see how it works. 13:05:28 +1 to trying with a couple of sections -- maybe one that works well and one that is harder :-) 13:06:07 Sharron: We tend to treat the whole thing linearly & it doesn't happen linearly. 13:06:46 ... feedback: this is areally nice document, but this is not how it happens in the real world. this paints step-by-step, but real worlks is much more messy 13:06:54 ... iteration is so important 13:07:07 ... checklist appraoch doens't work 13:07:37 ... let's stay mindful of fact that this is not a step-by-step linear process 13:08:01 ... not waterfall. agile environments 13:08:13 q+ 13:08:30 wonder if we need to user test with 'outsiders' (like Sharron tried) - we're maybe too close to content and structure 13:09:03 ... it would help people find their way through the doc, but maybe not meet reality 13:09:45 q+ 13:09:53 q+ to ask Sharron if idea for change 13:11:05 Shadi: Your last comment "that it does not convey the meesiness" of web accessiiblity impelemtation. So if we keep the document as it is now, we have the problem already. So perhaps by making these changes we would be able 13:11:16 ...to make the cahnge. 13:11:19 [ /me thinks the re-organization would actually help the iterative way it is addressed -- it's easier to jump around....] 13:12:11 q? 13:12:14 ack wayne 13:12:40 Wayne: There are not discrete, separate things that must be done so yes, in fact we do need to consider that. 13:13:20 ...since most start with a completely developed web site that is not accessible, there are things missing from here. There is the triage question. 13:13:56 q+ 13:14:09 q- 13:14:10 ...the example I put in my email was from a medical org that said how shocked he was realizing that a medical emergency page was inaccessible. 13:14:17 q- 13:14:36 zakim, who is muted? 13:14:36 I see Shawn, Howard, EricE, Bim muted 13:14:41 in an effort to move forward, I'll send my comments offline 13:15:39 Sharron: good point, too. for an absolute beginner, it is good to have clear points for them 13:15:55 Shadi: More compartmentalization emphasizes the linear nature. But we must also meet the needs of the many people who come to us and say "Just tell me what to do" 13:16:31 q+ Jon 13:17:04 ack j 13:17:07 Sharron: And more about how it happens in an agile environment. 13:17:39 +1 to incorporating some aspects of an agile approach into intro (or elsewhere) 13:18:39 q+ to ask followup 13:18:45 q+ to ask followup to Jon 13:19:02 Jon: I took this and tried it on an actual website in a client development environment. I saw very little difference between this and the HHS checklist. I still had to go and find clarification elsewhere in order to understand. I like the UI, I like the way it looks, I think the content is lacking. It is not especially useful in a real world application. 13:19:05 ack me 13:19:06 shawn, you wanted to ask followup and to ask followup to Jon 13:19:29 Shadi: You want more detail or what? 13:20:58 Jon: I like the idea of expanding the points directly and would ask for more examples 13:21:26 http://w3c.github.io/wai-planning-and-implementation/Overview.html 13:23:12 zakim, mute me 13:23:12 Jon should now be muted 13:23:18 Shadi: Another point was within Roles... there appears a sidebar. People may find this distracting. 13:23:50 Shawn: When Kevin goes to reorganizae this it may not work right floated anyway. 13:24:04 Shadi: What was the concern about this? 13:25:24 Shawn: It is difficult when the font is magnified. My focus at 100% is drawn to the examples, go back to read the parpagraph, but visually my attention continues to pull to the right. it is worse when the font is expanded. 13:25:31 example should wrap under as zoom kicks in maybe? 13:25:45 Shadi: Does this happen on all web sites where you have multi-column layout. 13:26:02 Shawn: No this is not really multi column it is a floated bit of content 13:26:32 Shadi: What would be a way to address? 13:27:03 as I zoom in Chrome37, I get just 1 word/line for example - becomes hard to read 13:27:31 Could be built a bit more responsive, which would address this 13:27:40 hear hear to going to responsive design 13:27:41 ... or address the zoom 13:28:02 +1 RWD 13:28:16 Wayne: Where it would be in the linear reading order for a screen reader. 13:28:20 and that might address the big blank left col too :) 13:28:37 Shawn: Jon did you ahve issue with that? 13:28:45 s/ahve/have 13:28:46 http://w3c.github.io/wai-planning-and-implementation/Overview.html#resp 13:29:20 Zakim, unmute me 13:29:20 Jon should no longer be muted 13:29:21 that big blank left column was a huge challenge with illustrations 13:29:46 q+ to wonder what the _benefit_ of the floated column is? 13:30:07 q? 13:30:13 zakim, ack me 13:30:13 unmuting Howard 13:30:14 I see EricE on the speaker queue 13:30:22 Regrets: Vicki, Denis, Helle 13:30:58 ack me 13:30:58 Jon: Browsers handle the zoom very differently. Things fall out of place according to that fact. 13:30:59 EricE, you wanted to wonder what the _benefit_ of the floated column is? 13:31:06 Zakim, mute me 13:31:06 Jon should now be muted 13:31:13 Eric: I wonder what is the benefit of the floating column? 13:31:42 Jan has joined #eo 13:31:57 zakim, mute me 13:31:57 EricE should now be muted 13:32:00 Shadi: I am the least aesthetic person but at least that floated content breaks the terrible, text heavy presentation. Do others find that? 13:32:01 q+ 13:32:38 Kevin: That was the rationale - to inlcude a bit of an aside and use it to break the long text flow. Making it less challenging to look at and read. 13:32:46 [ I still think that the re-org will break up the blocky flow (and support putting the examples in an sx-col] 13:32:51 ack a 13:33:11 q+ 13:33:30 s/(and support putting the examples in an sx-col]/(and support putting the examples in an ex-col) 13:33:37 AnnaBelle: When Jon and kevin and I are able to introduce illustrations, I know that won't be for a while yet, but it will be a tremendous help to the wall of text effect. 13:33:50 [shawn finds that it really distrupts her reading flow... though doesn't want to hold things up... ] 13:34:14 zakim, mute me 13:34:14 Howard should now be muted 13:34:42 AnnaBelle: I don't care deeply passionately. I like it OK now but this seems like another kluge and that RD would help. 13:35:08 That can be helpful though 13:35:15 Not all distraction is bad 13:35:43 Sharron: Seems like if it is distracting and disruptive that is enough to determine we should not do it. 13:35:57 ack me 13:36:01 Shadi: Yes we have determined that it must be at least responsive. 13:36:32 s/ [shawn finds that it really distrupts her reading flow... though doesn't want to hold things up... ]/ [shawn finds that it really distrupts her reading flow... though doesn't want to hold things up... so I guess willing to let it go] 13:36:33 It's too easy for people to just stop paying attention when reading so much text in this format 13:36:41 Bim: I wonder if it has been double tested. Put up to 200% ib browser zoom. If I do that and use page up, page down I never find it. 13:37:10 Kevin: It has not yet been seriously tested since it was a proposed but not finalized design choice. 13:37:16 zakim, mute me 13:37:16 Shawn should now be muted 13:37:32 Shadi: As a magnification user, what are your thoughts? 13:38:27 Bim: I am not that keen on asides like this. I find it can break up my reading flow. The line of separation is one thing and also with browser zoom, there becomes only one word on each line. It is not easy reading. 13:38:34 with even minor magnification/zoom it's a *real* problem because you have to scroll up and down to get to the different sections 13:39:14 responsive +1 13:39:24 Shadi: So 2 options: Invest time and effort to make this responnsive and the other is to put it as an inline section. 13:39:32 Sharron: +1 responsive 13:40:00 q+ 13:40:24 +1 to responsive 13:40:27 ack annabelle 13:40:51 +1 inline (for sake of expediency) 13:41:15 AnnaBelle: For RD it would be a cluge if we did it for only this one. EasyChecks needed it more, in my opinion. 13:42:15 q+ 13:42:17 +1 to inline, for the sake of simplicity. It could have the same styling, which would break up the reading flow as well. 13:42:20 Kevin: It is not straightforward, it would likely not be a complete responsive solution. I don't know that we have the resources to do it at this time. It would only be responsive in terms of that one feature, the asides 13:42:55 +1 to inline for the sake of getting it done. 13:43:01 ...knowing the resources we have, it would be a significant challenge. 13:43:16 AnnaBelle: We can't do responsive and not address the navigation. 13:43:35 +1 to eric that it has the same styling so it would break up the reading flow 13:43:51 ack a 13:44:23 ack m 13:44:27 ack me 13:44:51 Shadi: OK we will go with inline for now and if other resources become available we could reconsider 13:45:23 Shawn: And maintain the different visual styling to set it apart somewhat...but not too much. 13:46:08 zakim, mute me 13:46:08 kevin should now be muted 13:46:23 Topic: WCAG Report Tool 13:46:42 http://w3c.github.io/wcag-em-report-tool/dist/ 13:48:13 Shadi: The WCAG-EM Report Tool has gotten comments - thank you all for making them. We have incorporated many, have put some on the wish list for things we may not be able to address right now. But in the future, people may be contibuting as they use it and want more features. 13:48:27 +??P24 13:48:52 zakim, ??P24 is Wilco 13:48:52 +Wilco; got it 13:49:17 ...easy questions first. We had designed the Tool to ahve a Help page. Now it seems we have inline info boxes and an extensive Intro, so the Help section is being deemphasized. We have not found anything else that would need a Help page...anyone? 13:50:03 Love inline headings on Start page 13:50:17 ...there was a comment on the heading called "About this Tool" Suggestions is to rename "Saving Your Work" reactions? 13:50:26 zakim, unmute me 13:50:26 Shawn was not muted, shawn 13:51:23 s/ahve/have/ 13:51:36 Shawn: I agree with what Andrew said and am willing to take a pass at clarifying them. 13:51:48 Shadi: let me take a look and get back to your offer. 13:52:12 -Jon 13:52:23 ack Wilco 13:52:34 zakim, who is on the phone? 13:52:34 On the phone I see AnnaBelle, Shawn, kevin (muted), Howard (muted), EricE (muted), Shadi, Bim, Andrew, Sharron, PaulSchantz, metzessive, Wayne_Dick, Wilco 13:52:57 -Wilco 13:53:44 Shadi: Comment is about increasing default font size. It is already a larger size than that used on the WAI Website. 13:53:55 Shawn: No it is quite a bit smaller side by side 13:54:19 I show font sizes as 15px on Wilco's and 14.4px on WAI 13:54:24 Shadi: I don't have that outcome. The question is do others feel that teh default text size should be increased? 13:54:25 +1 to increase text to at least 16px. 13:54:46 [maybe it's because the WAI website is picking up my OS settings for larger font, but the tool is not] 13:54:50 s/teh/the 13:54:56 +??P22 13:55:06 Zakim, ??P22 is Wilco 13:55:06 +Wilco; got it 13:55:08 ack me 13:55:38 Eric: I think we should generally have a 16 pixel baseline. 13:55:55 zakim, mute me 13:55:55 EricE should now be muted 13:56:08 ...I would like to have the line length reduced on the Start page. As it is now it is incredibly long. 13:56:37 When I play with 16px font size I like it 13:56:40 +1 to shorter line length on start page 13:56:43 Shadi: Wilco can you remind me how it is sized now? 13:57:13 Wilco: 15 px for text, and I don't recall the others. 13:57:29 Shadi: So if we increase to 16 would the design hold? 13:57:52 ack me 13:57:55 Shawn: My alarm bells go off when we talk about pixel font size. 13:58:13 Zeldman's thinking on font sizing has changed -- and he's a leader in this 13:58:20 If you just leave it as 1 em and not set the REM, shouldn't it just default to browser default? 13:58:29 zakim, mute me 13:58:29 EricE should now be muted 13:58:32 s/talk about pixel font size./talk about pixel font size -- has that changed?/ 13:58:35 Eric: It means just removing the font declaration becasue browser default is 16 pixels 14:00:29 [Opera -- and I have larger font size settings in O/S and browser] 14:01:05 Eric: browsers are able to zoom pixels easily today. Standard behaviour is 16 px as a base font size, that means 1(r)em = 16px. 14:01:16 Shadi: OK...next comment was to reduce line length on first page, reactions? 14:02:20 Shawn: Personally, I like having the line length remain full screen because I can change the length by changing the browser window. Just one opinion. 14:02:36 Shadi: I agree, I like the longer line length. 14:03:02 zakim, ack me 14:03:03 unmuting Howard 14:03:03 I see no one on the speaker queue 14:03:52 Howard: I like a shorter line length, but I have the option of reducing the window size and so the user has control. 14:04:01 zakim, mute me 14:04:01 Howard should now be muted 14:04:09 Personally I think we should strive to meet the easily achieved aspects of AAA 14:04:15 Shadi: You only have a full line length here and a few other place. The purpose is not to read. 14:04:23 preference for a slightly shorter line length, but then I change window size all the time, so not an issue really for me 14:04:27 ...am not hearing strong opinions. 14:04:31 q+ 14:04:53 Shawn: Note that just strictly visually, it would look nicer to ahve it aligned with the bar at the top. Not a strong feeling. 14:04:59 If we implemented a grid layout in the CSS, things would align much easier. 14:05:22 Wilcon: We might push the Start button beneath the fold. I don't think we should do that. 14:05:32 s/Wilcon/Wilco 14:05:33 Move the what below the fold? 14:05:41 nm 14:05:46 NM 14:05:48 never mind 14:06:02 yep. a broad sheet 14:06:14 q+ 14:06:21 ack wilco 14:06:28 ack met 14:07:01 Jon: There are ways to keep it above the fold regardless, have things float behind it. 14:07:27 Eric: I can live with it. 14:08:20 Jon: I beleive that we should at least strive to meet the easiest parts of AAA conformance. 14:09:05 ..the 80 character goal is easy to meet, why not try it? 14:10:10 Wayne: This enlargement stuff is tricky. If you have an absolute positioned thing and everything gets really big, so does the thing. It is one thing to have 80 characters per line and another to have 10...or even 20. 14:10:39 ...it will take a substantial amount of thought and planning. 14:11:19 Shadi: I am pretty certain this meets the requirement. We are not talking about accessibility requirements, we are talking about usability and clarity. 14:11:35 The first line is 154 characters on my browser 14:11:52 so? 14:12:23 it's cool. 14:12:27 Shadi: And yet you can reduce the browser window size to be 80 characters. 14:12:37 zakim, mute me 14:12:37 metzessive should now be muted 14:13:32 zakim, unmute me 14:13:32 metzessive should no longer be muted 14:13:36 Shawn: Jon and Eric, are you OK with leaving the line length as is, or still address that? 14:13:47 Eric: Yes OK 14:14:02 Jon: Yes it is fine, totally fine 14:14:19 zakim, mute me 14:14:19 metzessive should now be muted 14:15:43 Shadi: Next comment stemmed from discussion of the concern that the Next button, currently on the right hand side can be missed by magnifcation. Thanks to Sharron, AnnaBelle, Andrew, and Shawn for research. 14:16:29 new information from Caroline Jarrett at https://www.w3.org/WAI/EO/wiki/WCAG-EM_Report_Tool_Comments#button_placement 14:16:37 ...the question is to keep them as they are , another to place them in the center, another to palce them side by side on the left, and one to have only the Next button, remove the Previous. 14:16:49 +1 left justified previous and next 14:18:19 feedback in WAI-IG supports LHS, else can be missed - http://lists.w3.org/Archives/Public/w3c-wai-ig/2014JulSep/thread.html#msg69 14:18:26 Shawn: Caroline actually disagreed with one of the articles. Her research and UX testing supports placing as close as possible to the left side of the last active field 14:18:43 q+ 14:18:47 AnnaBelle: Makes sense, that was helpful Shawn. 14:19:56 zakim, who is making noise? 14:20:08 shawn, listening for 10 seconds I heard sound from the following: Shawn (4%), Wayne_Dick (4%) 14:20:12 +1 14:20:16 q+ 14:20:26 q+ 14:20:26 ack me 14:20:36 Shadi: I am extremely surprised. This is a major redesign change. Yesterday I booked a rental car, the buttons were on left (Back) and right (forward). Saw this in airlines, Amazon, other online retail things. I would cognitively expect it to be on the right. This may be the most recent research but I don't see it in practive. 14:20:50 from wiki: Based on all the input and also playing around with it with my user hat on, I now suggest that we have at the bottom a "Next" button left-aligned, no Previous button, and a Back to top link to get them to the overall actions (including Save Report) and the page navigation bar. {Shawn} 14:21:38 q+ 14:21:48 ack w 14:22:18 Bim: My expectation was always to put things on the right. If the Previous button is on the left, the right hand Next button is easily found and used by right hand mouse users (a majority) 14:22:28 Wayne: Fully right justified? 14:22:37 ack me 14:22:42 q+ 14:22:47 Bim: Yes, not in a center placed location. 14:23:05 Hard to hear Andrew 14:23:08 zakim, mute me 14:23:08 Bim should now be muted 14:23:25 Andrew: Just because it is in common use however does not mean that they ahve user tested it. I posed the questin as well and got feedback NOT to put it aligned right. 14:23:41 ack me 14:24:02