W3C

- DRAFT -

Education and Outreach Working Group Teleconference

29 Aug 2014

See also: IRC log

Attendees

Present
AnnaBelle, Shawn, Howard, kevin, EricE, Shadi, Bim, Andrew, Sharron, PaulSchantz, metzessive, Wayne_Dick, Jon, Wilco
Regrets
Vicki, Denis, Helle
Chair
Shawn
Scribe
Sharron

Contents


<trackbot> Date: 29 August 2014

trackbot, start meeting

<trackbot> Meeting: Education and Outreach Working Group Teleconference

<trackbot> Date: 29 August 2014

<scribe> Scribe: Sharron

Implementing Accessibility

<shawn> http://w3c.github.io/wai-planning-and-implementation/Overview.html

Implementation Plan

<shawn> e-mail comment from Shawn: http://lists.w3.org/Archives/Public/w3c-wai-eo/2014JulSep/0053.html

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.

Shawn: It was an idea

Shadi: It was a great one, but will take some significant rewriting.
... first it will make the Key Points clearer and then it will make the relationship direct.

Kevin: Sounds great to me.

Shadi: What was the reaction of the group?

<paulschantz> +1 to Shawn's idea

<shawn> Sharron: skeptical...

Sharron: My first reaction is that this is too linear of a treatment, things are too interrelated

<paulschantz> does this mean folding "more detail" section into key actions section?

<Andrew> +1 to Sharron's opposition

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.

<shawn> [ Paul - kinda. the key actions would be expandable to have more detail under each.]

Shadi: Do you have an example?

<kevin> http://w3c.github.io/wai-planning-and-implementation/Overview.html#resp

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.
... one example only.

Shadi: If we adopt that approach we would need to make that consideration.

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.

Shadi: You are assuming that Key Actions would still be expanadable, yes or no?

Paul: Yes

<shawn> 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.

Paul: 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
... So when you expand the section it very closely follows the sequence of the Key Points about it.

Shadi: It does not in fact in all cases. But maybe you are saying that they should.

<Andrew> not such a close match in other sections

<Zakim> Andrew, you wanted to say might also make it harder to skim

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.

<Andrew> maybe we highlight some key words in the 'more detail' discussion?

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

what I was trying to address.

<paulschantz> document structure might not match usage

scribe: 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.

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?

<Zakim> kevin, you wanted to talk about the purpose of the key actions and more details section

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.

<shawn> [ /me likes the clarification of "why" and "how"]

<kevin> http://w3c.github.io/wcag-em-report-tool/dist/#/audit/test

Kevin: an expand capability. It seems what we are suggesting here with all the expand features would be a challenging read. So perhaps an arrow expand collapse would minimize the distraction.
... we need a "Why and How" within each section.

Shadi: How does that help? If you come across a Key Action and you don't understand...

<shawn> [ /me also agrees for ex-col on key actions AND also a general section ]

Kevin: You would have a mix of both.

<shawn> +1 to Shadi's summary

<Andrew> sounds like applying the old Lotus Notes 'twisties' as he bullets

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

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

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.

<shawn> zaki, mute me

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.

Shawn: That addresses my concern

Andrew: Yes, I suspect so.

Shadi: It looks like we can try this and see how it works.

<shawn> +1 to trying with a couple of sections -- maybe one that works well and one that is harder :-)

<shawn> Sharron: We tend to treat the whole thing linearly & it doesn't happen linearly.

<shawn> ... 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

<shawn> ... iteration is so important

<shawn> ... checklist appraoch doens't work

<shawn> ... let's stay mindful of fact that this is not a step-by-step linear process

<shawn> ... not waterfall. agile environments

<Andrew> wonder if we need to user test with 'outsiders' (like Sharron tried) - we're maybe too close to content and structure

<shawn> ... it would help people find their way through the doc, but maybe not meet reality

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
... to make the cahnge.

<shawn> [ /me thinks the re-organization would actually help the iterative way it is addressed -- it's easier to jump around....]

Wayne: There are not discrete, separate things that must be done so yes, in fact we do need to consider that.
... since most start with a completely developed web site that is not accessible, there are things missing from here. There is the triage question.
... 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.

<metzessive> in an effort to move forward, I'll send my comments offline

<shawn> Sharron: good point, too. for an absolute beginner, it is good to have clear points for them

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"

Sharron: And more about how it happens in an agile environment.

<Andrew> +1 to incorporating some aspects of an agile approach into intro (or elsewhere)

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.

<Zakim> shawn, you wanted to ask followup and to ask followup to Jon

Shadi: You want more detail or what?

Jon: I like the idea of expanding the points directly and would ask for more examples

<shawn> http://w3c.github.io/wai-planning-and-implementation/Overview.html

Shadi: Another point was within Roles... there appears a sidebar. People may find this distracting.

Shawn: When Kevin goes to reorganizae this it may not work right floated anyway.

Shadi: What was the concern about this?

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.

<Andrew> example should wrap under as zoom kicks in maybe?

Shadi: Does this happen on all web sites where you have multi-column layout.

Shawn: No this is not really multi column it is a floated bit of content

Shadi: What would be a way to address?

<Andrew> as I zoom in Chrome37, I get just 1 word/line for example - becomes hard to read

<kevin> Could be built a bit more responsive, which would address this

<AnnaBelle> hear hear to going to responsive design

<kevin> ... or address the zoom

<metzessive> +1 RWD

Wayne: Where it would be in the linear reading order for a screen reader.

<Andrew> and that might address the big blank left col too :)

Shawn: Jon did you have issue with that?

<shawn> http://w3c.github.io/wai-planning-and-implementation/Overview.html#resp

<AnnaBelle> that big blank left column was a huge challenge with illustrations

Jon: Browsers handle the zoom very differently. Things fall out of place according to that fact.

<Zakim> EricE, you wanted to wonder what the _benefit_ of the floated column is?

Eric: I wonder what is the benefit of the floating column?

Shadi: I am the least aesthetic person but at least that floated content breaks the terrible, text heavy presentation. Do others find that?

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.

<shawn> [ I still think that the re-org will break up the blocky flow (and support putting the examples in an ex-col)

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.

<shawn> [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]

AnnaBelle: I don't care deeply passionately. I like it OK now but this seems like another kluge and that RD would help.

<metzessive> That can be helpful though

<metzessive> Not all distraction is bad

Sharron: Seems like if it is distracting and disruptive that is enough to determine we should not do it.

Shadi: Yes we have determined that it must be at least responsive.

<metzessive> It's too easy for people to just stop paying attention when reading so much text in this format

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.

Kevin: It has not yet been seriously tested since it was a proposed but not finalized design choice.

Shadi: As a magnification user, what are your thoughts?

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.

<shawn> with even minor magnification/zoom it's a *real* problem because you have to scroll up and down to get to the different sections

<Wayne> responsive +1

Shadi: So 2 options: Invest time and effort to make this responnsive and the other is to put it as an inline section.

Sharron: +1 responsive

<Bim> +1 to responsive

<Andrew> +1 inline (for sake of expediency)

AnnaBelle: For RD it would be a cluge if we did it for only this one. EasyChecks needed it more, in my opinion.

<yatil> +1 to inline, for the sake of simplicity. It could have the same styling, which would break up the reading flow as well.

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

<Bim> +1 to inline for the sake of getting it done.

Kevin: knowing the resources we have, it would be a significant challenge.

AnnaBelle: We can't do responsive and not address the navigation.

<shawn> +1 to eric that it has the same styling so it would break up the reading flow

Shadi: OK we will go with inline for now and if other resources become available we could reconsider

Shawn: And maintain the different visual styling to set it apart somewhat...but not too much.

WCAG Report Tool

<shadi> http://w3c.github.io/wcag-em-report-tool/dist/

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.
... easy questions first. We had designed the Tool to have 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?

<AnnaBelle> Love inline headings on Start page

Shadi: there was a comment on the heading called "About this Tool" Suggestions is to rename "Saving Your Work" reactions?

Shawn: I agree with what Andrew said and am willing to take a pass at clarifying them.

Shadi: let me take a look and get back to your offer.
... Comment is about increasing default font size. It is already a larger size than that used on the WAI Website.

Shawn: No it is quite a bit smaller side by side

<AnnaBelle> I show font sizes as 15px on Wilco's and 14.4px on WAI

Shadi: I don't have that outcome. The question is do others feel that the default text size should be increased?

<yatil> +1 to increase text to at least 16px.

<shawn> [maybe it's because the WAI website is picking up my OS settings for larger font, but the tool is not]

Eric: I think we should generally have a 16 pixel baseline.
... I would like to have the line length reduced on the Start page. As it is now it is incredibly long.

<AnnaBelle> When I play with 16px font size I like it

<Andrew> +1 to shorter line length on start page

Shadi: Wilco can you remind me how it is sized now?

Wilco: 15 px for text, and I don't recall the others.

Shadi: So if we increase to 16 would the design hold?

Shawn: My alarm bells go off when we talk about pixel font size -- has that changed?

<AnnaBelle> Zeldman's thinking on font sizing has changed -- and he's a leader in this

<metzessive> If you just leave it as 1 em and not set the REM, shouldn't it just default to browser default?

Eric: It means just removing the font declaration becasue browser default is 16 pixels

<shawn> [Opera -- and I have larger font size settings in O/S and browser]

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.

Shadi: OK...next comment was to reduce line length on first page, reactions?

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.

Shadi: I agree, I like the longer line length.

Howard: I like a shorter line length, but I have the option of reducing the window size and so the user has control.

<metzessive> Personally I think we should strive to meet the easily achieved aspects of AAA

Shadi: You only have a full line length here and a few other place. The purpose is not to read.

<Andrew> preference for a slightly shorter line length, but then I change window size all the time, so not an issue really for me

Shadi: am not hearing strong opinions.

Shawn: Note that just strictly visually, it would look nicer to ahve it aligned with the bar at the top. Not a strong feeling.

<metzessive> If we implemented a grid layout in the CSS, things would align much easier.

Wilco: We might push the Start button beneath the fold. I don't think we should do that.

<metzessive> Move the what below the fold?

<metzessive> nm

<metzessive> NM

<metzessive> never mind

<metzessive> yep. a broad sheet

Jon: There are ways to keep it above the fold regardless, have things float behind it.

Eric: I can live with it.

Jon: I beleive that we should at least strive to meet the easiest parts of AAA conformance.
... the 80 character goal is easy to meet, why not try it?

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.
... it will take a substantial amount of thought and planning.

Shadi: I am pretty certain this meets the requirement. We are not talking about accessibility requirements, we are talking about usability and clarity.

<metzessive> The first line is 154 characters on my browser

<metzessive> so?

<metzessive> it's cool.

Shadi: And yet you can reduce the browser window size to be 80 characters.

Shawn: Jon and Eric, are you OK with leaving the line length as is, or still address that?

Eric: Yes OK

Jon: Yes it is fine, totally fine

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.

<shawn> new information from Caroline Jarrett at https://www.w3.org/WAI/EO/wiki/WCAG-EM_Report_Tool_Comments#button_placement

Shadi: 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.

<Wayne> +1 left justified previous and next

<Andrew> feedback in WAI-IG supports LHS, else can be missed - http://lists.w3.org/Archives/Public/w3c-wai-ig/2014JulSep/thread.html#msg69

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

AnnaBelle: Makes sense, that was helpful Shawn.

<Wilco> +1

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.

<shawn> 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}

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)

Wayne: Fully right justified?

Bim: Yes, not in a center placed location.

<Howard> Hard to hear Andrew

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.

<shawn> [ Shawn finds Bim's experience interesting. Also note that screen magnification users will still see it on the left.]

Kevin: I have spoken with Caroline. She has done extensive research...she knows her stuff. There have been various configurations that test well. I understand that the common convention is to have it right aligned but that does not mean that left-justified does not test well.

<AnnaBelle> q

Shadi: I understand that there are widely used conventions that are not necessarily good for users.

<shawn> [ the next button can include the step text (like we do in the tutorials)]

Wilco: It is common that these buttons will be on the right, but we can always make it wider to be sure that magnification can find it.

Shadi: There is a suggestion to also add the next step onto the button, making it naturally wider.

AnnaBelle: My question about the web sites you visited Shadi, was the text on the left and the form field on the right?

<Howard> agree with changing color of previous step

<Zakim> shawn, you wanted to say no one will miss it on the left. some people might miss it on the right.

<metzessive> yep

AnnaBelle: in this case, the form field spans the full width. As it is now, you can barely see the Previous which could be a cue to look right for the Next.

<Howard> I don't

<AnnaBelle> no to 10 more mins. sorry

Shawn: two points. No one will miss it if we put it on the left. Some people will miss it if we put it on the right.
... we could the buttons together in a bar...something there to connect them

<Howard> I look for it on the right

Shadi: Actually, I will miss it on the left.

Wilco: me too

Wayne: In this example, Bim and I may not be the best examples. Magnification has only a 10% adoption rate. We are experinced users not typical.

Shadi: Let's go wioth the suggestion to increase visual emphasis of previous and connect them somehow according to Shawn's suggestion and see how that looks.

<Howard> \ bye all

Shawn: And mentioned putting next step text.

<yatil> +1 to Shawn. In General.

Shadi: next step with the tool is to actually go into more formal review process.

<Bim> +1 to Shawn, don't like making Previous more obvious, it might beg to be clicked by mistake.

<Wayne> we just proved at CSULB usability lab that reading with zoom is slower and less accurate than reading with reflow. Our statistical significance is generally p<.002.

<Andrew> east coast/west coast?

<Andrew> s/east coast/west coast?//

Shawn: Let's do Last call for addiitonal comments by Tuesday midnight Hawaii time

Goodbye and hello Bim

<Andrew> great that you'll stay on in EOWG Bim :)

Shadi: Bim is leaving the team, this is her last meeting as staff. But she likes EO and so will continue as a volunteer and will continue as Invited Expert. So we will still ahve her as a collague. Thanks very much for your conributions as staff, and look forward to continuing the collaboration with you as a volunteer.

<shawn> thanks for your past & future work, Bim!!! :-)

Shawn: Thanks for past and future work.

<yatil> Thanks Bim!

Sharron: Thank you Bim!

<Wilco> thanks Bim, bye!

Shawn: So informal usability testing with the tool, final input by Tuesday and will then be asking for approval to publish as Beta

Shadi: Thanks all

Wayne: Works well in large print for me

<metzessive> bye

<Wilco> bye

trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/08/29 14:38:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Plann/Plan/
Succeeded: s/ahve/have/
Succeeded: s/Shadi/Shawn/
Succeeded: s/Shawn/Shadi/
Succeeded: s/mperhaps/perhaps/
Succeeded: s/ahve/have/
Succeeded: s/(and support putting the examples in an sx-col]/(and support putting the examples in an ex-col)/
Succeeded: 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]/
Succeeded: s/ahve/have/
Succeeded: s/teh/the/
Succeeded: s/talk about pixel font size./talk about pixel font size -- has that changed?/
Succeeded: s/Wilcon/Wilco/
WARNING: Bad s/// command: s/east coast/west coast?//
Found Scribe: Sharron
Inferring ScribeNick: Sharron
Default Present: AnnaBelle, Shawn, Howard, kevin, EricE, Shadi, Bim, Andrew, Sharron, PaulSchantz, metzessive, Wayne_Dick, Jon, Wilco
Present: AnnaBelle Shawn Howard kevin EricE Shadi Bim Andrew Sharron PaulSchantz metzessive Wayne_Dick Jon Wilco
Regrets: Vicki Denis Helle
Found Date: 29 Aug 2014
Guessing minutes URL: http://www.w3.org/2014/08/29-eo-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]