Update: Images and Forms tutorial

Shawn: Fourteen people answered, great job everyone! Eric is processing them, will be working through, may be checking in with you and bring back any comments that need discussion. In the meantime, let's take a minute to introduce Melody to everyone

Shawn: Melody, we are pleased to have your development skills on the group, thanks for your tutorial comments - those will be addressed and reported next week. I wanted to announce that Helle is leaving the active participation in the group so she is stepping back.

All: Will miss Helle very much! (Round of intros for new member Melody Ma)

WCAG-EM Report Tool

<shawn> https://www.w3.org/2002/09/wbs/35532/eo-weekly-20150206/results#xq5

Shawn: here are the results of the survey, people may wnat to skim new comments...Shadi do you want to take it away?

Shadi:Thanks everyone, Melody identified a bug and there was a lot of very good input. Most people are happy with expand/collapse function. The answer to the question about more bullets is "Yes." There will be a bit more text, including the workaround for adding specific SCs...there was a suggestion to reorganize some of the information, making How it works in your browser more clear, change the titles a bit, etc.

Shawn:The main point being made is that there is no auto save, is that right?

Shadi: Yes and that it is all client based and that reports can be saved and reloaded. That is important too but not as improtant as how it is NOT auto saved.

Shawn:1. Could leave the text, change the title 2. Could have this expanded by default. 3. Could pull most important info to always display and collapse the others ...any comments on these 3 options?

Brent:I like option 1 -- "Important: About Saving Data"

<Howard> lean 2

<shawn> mildy #3

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

<Howard> actually, 1 & 2 - should change title and leave the text visible

<yatil> #3, #2, #1, in that order

<Andrew> sort or 3 (i.e. no auto save)

Shawn: Look at the first page, the question is for the section "How it works..." there is important information in there and we need to decide how to present it.

<melodyma> #2 or #3 and change the title

<metzessive> 2, 1, 3

<Brent> yes

<Howard> for me, yes

<yatil> yup.

<Lydia> yes

<melodyma> Yes

<paulschantz> 3, 2, 1 (like Eric)

Andrew: Some of the stuff is about how it works but the fact that it does not auto save is not really about that. If we could pull out that one thing, the rest could collapse.

Shadi: Do people assume that the tool saves anything at all? Having it as a stand-alone note might be odd. We would warn them about something that they may not expect anyway

Andrew:Yes and this is not really about the browser

Shadi:Yes it is more about How This Tool Works

Shawn:All three of the bullets are related to saving.

Shadi: Because it is an unusual function...and as you pointed out, Shawn, the fact that you can go back and forth within the tool and the data is saved.

Shawn:Saving and reUsing Data in your browser

Paul: People are becoming more used to auto saving such as in Google docs so a note about that would be wise.

Jon:I think we should be consistent with whatever other web applications do.

Shadi:But is we have an an always displayed Note that says it doesn't save, it might seem odd out of context.

Paul: A "Remember to Save your work" note in the header or footer?

Andrew:we also have 'save' and 'open' in the top menu

Melody: Most modern web apps tend to save, it seems to me there should be a "This is Important" note due to the unique aspect...in most apps, you would save within an account. Since here there is no account, it seems that should be explained.

Shawn:Given all of the options, I don't see the need to makeit collapsable.

Lydia:This would be great if more information is added

Shawn: We think this is important information so I question whether people should be required to expand a section in order to read it...Let's say that if some information is always visible and the Tip for Using the Tool is expandable. Which of those three bullets need to be visible by default and which can be collapsed?

Shadi:I prefer to have a design that allows us to add bullets in the future if needed.

Andrew:The bottom line of "How.." could possibly move into "Tips..."

Shadi:Then make the title more specific to the most important point.

Andrew: potential issue with one open / one collapsed heading is different heading behavior on page

Shawn:..and don't make it collapsible

Shadi:That will change the styling, which may or may not be a problem...if we have an expandable heading on the first page, it is because you are likely to read it only once and once you are familiar you would not expand it again.

Andrew:+1 to Shadi - make min permanent info just a note

Brent: I would collapse it once I have understood it.

Shawn: But it would be expanded everytime you return

Lydia: Could you have the first item always displayed and the options to see more by expaning? That shows that there is some information within the heading to let people know and to display the most important point first.

<Andrew> Lydia's description is becoming common from my observations too

Shawn:Shadi, do you have a proposal based on the input you have received?

Shadi:Proposed to keep the two headings, collapsed by default; improve heading titles to make contents more clear - add important perhaps.
...to Melody's comment about the unique nature of the tool, does the fact of "the tool does not auto save" have to be called out and displayed or is it sufficient to leave it within the collapsed section?

<Andrew> +1 to closed sections with permanent note on 'no auto save'

<paulschantz> +1 like Andrew

Melody:That is an important fact and should be permanently visible, the rest could be collapsed.

<Howard> +1 to Paul like Andrew

Shadi:Does anyone want to speak against this suggestion?

<yatil> +1 to Howard like Paul like Andrew

Shawn:I agree with having the info about the save be permanently displayed. I don't think we need two collapsable sections, could be merged into one.

<Sharron> +1

<Sharron> Shadi: Some of the information really is tips, but the other one is more basic instructional

<Sharron> Shawn: Good point

<Andrew> 'how it works' + 'tips for use'

Melody:It could be a simple as "Important: This tool does not record or automatically save the information that you enter. Use the Save Report link (Ctrl + C or ? C) that is at the top of all pages to save your data in a file locally on your computer. See 'How to Save Your Work' below for more information."

Brent:Saving is critical information, Tips may or may not be used or important. Two different things.

Melody:Maybe there can be something explaining JSON, what it is and how to use it under a Saving section.

Shadi:If we look at Brent's use case, you would read the first one once to understand how to use the tool. But the second one you might come back to more often.

Shawn:Move the Save out as a permanent note, first heading would have 2 bullets, second would have 4

Shadi:The more important question is how the information is related

Brent:I understand the point about merging them but my own preference is to make the point that all of the first section is about Saving and even with a permanent note. But the second about Tips may be added to in the future so should be separated.

Shadi: Can we leave this to editor's discretion?

Shawn:Yes

<melodyma> @Shadi - Maybe some more information about the JSON download and upload when you're at it too

Shawn:There are no other objections and I don't - so go with the latest proposal

Shadi:There were other comments, a bug fix and others. We are working through them.

Melody:It would be helpful to highlight the JSON download techniques in the start page.

Shadi:Yes we will look at that as we go on. The next question was the changes we made to Step 2 and 3 and everyone seemed to like those changes.
...so remember that everything in Step 2 is optional and it is presented to you agin in Step 3 to help you choose the pages. Melody raised the question about short name, we had considered Handle but that was considered more jargony...question for the group: are we still happy with Short Name as the label?

Melody:What confused me was that there was already existing information in the field and trying to understand that. Once I removed and saw the placeholder text that provided more clarity. Text looks like placeholder text but is not.

Shawn:Oh, I never saw that.

Shadi:Yes I can see the source of confusion. If you remove it, does that address yourconcern?

Melody: Yes, removing that bug would help.

<Andrew> +1 to 'short name' (with hint that disappears on field focus)

Shadi:We still have a standing issue between the back and forth of Step 2 and 3 that we will examine in more detail after it is in use.

Shawn:Step 2 is the notes; Step 3 is the specific pages

Andrew:so, lets add a notes box on Step 2 to record technologies discovered

Brent: If you are asking for the technologies used, you are making people really look around the site before selecting pages. That is the rationale

<shawn> +1 to having on Step 2 a box for notes on technologies -- and leave the specific pages on Step 3

Andrew: Because you are just making notes in Step 2, what about a box to document what technologies you encounter?

<paulschantz> completely agree with Andrew

Sharron:yes good idea

Shawn: Currently in Step 2 you are just taking notes. On Step 3, you are actually entering specific web pages you are testing and the web technologies relied upon is just a list, not a url of a page on this website

<Brent> yes

<Andrew> yep

<Sharron> Shadi: Should we move the technologies back to step 2?

<Sharron> Sharron: yes

<Wayne> +1

<yatil> +1?

Shadi:Is anyone opposed to moving it back?

Shawn:From my perspective, the questions I raised are almost solved and if when in step 3, I had an edit button from which I could edit my notes in step 2, it would be entirely solved

Shadi: Not an automatic text edit, but a button

Shawn:Or a simple editable field would be great, but if I have to use a button to edit, that would be OK too.

Wayne:So you are saying that when I am in Step 3, I want to add text to Step 2, allow that addition within step 3?

Shawn:Yes.I will see my notes anyway in Step 3, so making it editable from that step 3 would be useful.

Eric:You could have them as disabled text boxes and styling them like the regular text.

Andrew: In the notes you make in step 2, you are told that the notes wont be part of the report. The menu at the top is not a save resport then, it is a save data?

Sharron:That is a good segue to next question - about the Save Report button. We could explain that in the Save dialogue although I shy away for using Save data because it is jargony.

Andrew:Jargony people will use this

Eric:What about "Progress" instead of report or data?

Wayne: Ilike that

<yatil> Or status?

Howard: "progress" is confusing<, I like "save report data"

<Howard> \ "save this stuff" :-)

Eric:Just "Save"

<kevin> +1 for Save and Load

Brent:Save data or Save

Paul:Remove the word "Report" from each of the icons at top

<Andrew> or save + reload

Shawn:Any objections to that change - it will say New Open Save

<paulschantz> +1

Howard:I am not sure, it makes it less clear. ...it may help define what you are working on - Save report

<Sharron> ...since the effort is about creating a report

<Andrew> new report | open | save

<shawn> +1

<kevin> +1 to Andrew

<Sharron> +1

<Lydia> that works

<Brent> Yes

<paulschantz> I don't like the repetition of the word "report"

<Andrew> new report | reopen | save

AnnaBelle:I like just plain "New"

Wayne: Me too

Jon:I think these are questions that would be better determined for Usability Testing. Are you planning on doing that?

Shadi: Suggest that we keep new report | open | save for now and do testing.

Shawn:OK with you and Wayne, AnnaBelle?

AnnaBelle:sure

Wayne:yes OK

Shadi:Now looking at theSave function survey question. Most people agreed that the control + S should not take you to the Save report page but some people suggested some form of dialogue or modal to confirm that a Save occured.
...for someone who is not used to how it saves it might be confusing. The current proposal is (because a modal would take some work) we could more easily do a javaScript dialogue or we could do nothing

<yatil> https://developer.mozilla.org/en-US/docs/Web/API/window.confirm

<Andrew> just 'where do you want to save'

<Andrew> keep it simple

Shawn:1. Leave as is / 2. Control + S gives a dialogue that says you are about to save and you confirm, get another confirmation / 3. Create modal overlay that presents info in more attractive way

Shadi: I like the idea of a modal very much but it si quite a bit of wok to get it to work correctly.

Eric:Some users may prefer not to have those repeated dialogues if they are saving often.

<shawn> +1 - I am an all the time saver and it would be a bit annoying

<Andrew> +1 to eric

<Brent> I confirm that

Eric: and browsers behave differently. FF displays the dialogue but Chrome immediately saves to download and doesn't display

<Brent> Chrome has settings for that - I think

<Brent> Wiindows as well

Jon: I get that behavior as well. Was there ever an idea that we could present this at CSUN?

Shadi:yes that is the hope, that we can tell the world about it at CSUN and get user feedback. We need to be careful. We do not want to release it if there are still bugs and/or annoyances.

Shawn:straw proposal is to add extra dialogue to version 1. For version 2 we plan a custom modal dialog

Shadi: For people using Macs with autosave - that becomes their issue?

Andrew: For those users, that is not necessarily a problem as they will know what is happening

Eric: I am totally fine if it saves to my Downloads folder

<shawn> +1

Shadi: Proposal; we will have an explanation of how the save works on the save page. Melody has suggested something on the start page to provide information on the save process. The assumption is that people who hit the save short cut know what they are doing. This is a temporary in version 1 until modal solution.

<Andrew> +1

<Sharron> +1

<Brent> +1

<melodyma> +1

<Howard> +1

<paulschantz> +1

<Wayne> +1

Wayne: Can it be done by CSUN?

Shadi: Wilco often likes a challenge, we will try to implement these changes, send out a survey on Tuesday.

Wayne: Can this just be the CSUN test product rather than an official release, beta vs v1?

Shadi: I don't the labeling makes that much difference, let's just put it out unless we have things that are really annoying. I hope we can have an official v1

Wayne: So the CSUN feedback is just for v2?

<Andrew> maybe a v0.9??

Shadi: We will put this in the survey.

Charter

Shawn: Make sure everyone is aware that our updated charter will be going to W3C AC review and the Deliverables section is updated with work for next 2 years.

F2F in May/Austin

<shawn> draft plan https://www.w3.org/WAI/EO/wiki/EOWG_F2F_May_2015

Shawn: make sure everyone saw the draft plan for that meeting, linked from agenda
... please update availability for specific days

<shawn> Wed:

<Lydia> maybe

<kevin> Yes

<shadi> yes

Sharron: yes

<shawn> yes

<Wayne> Available Mon-Th

<Brent> yes

<paulschantz> no

<shawn> Thur:

<Lydia> maybe

<Brent> yes

Shawn: we need to announce that the AccessU meeting it is an official F2F

<metzessive> Are we meeting at CSUN at all?

<melodyma> @Shawn - I likely won't be able to attend the F2F this time around :(

Mobile Accessibility Document

Shawn: There is new document being developed and EO has asked to do review of Public Working Draft before release. Not specifically nit picky but high level review of title, approach,etc

<Andrew> mobile a11y draft looks good in draft overall

<Andrew> http://w3c.github.io/Mobile-A11y-TF-Note/

Shawn: need volunteers for high level review

<Andrew> status has repetition

Shawn: from and EO standpoint, we would need to see if the title and abstract clearly indicate what it is, any potential misunderstandings, etc?

<Lydia> I'll read for high level overview

<Brent> I would like to look at it in that respect

Volunteers: Lydia, Brent, Wayne, Jon

<melodyma> I'll be happy to look at it too

<Brent> Where will we make comments?

Shawn: I will follow-up with Jeanne Spellman after the call and will send more info in email after I do that.

Wayne: Is this for a WCAG audience or what?

Shawn: Unknown
... and it is in GitHub, comments can be made there

Approval to publish

Shawn: Several items coming next week, be on alert for that

Dynamic Planning Tool

Shawn: Did not get to the dynamic planning tool, but Howard and some others had questions about that, so those who can stay can work with Kevin

Jon: I think it is a great resource, no questions

Kevin: Based on the comments there were design and approach ideas that I had for Wayne.

<shawn> [main EOWG meeting closed]

Sub-group meeting

<yatil> https://github.com/w3c/wai-tutorials/issues/233

Shawn: Wayne you had comments about how tutorials address longdesc.

<yatil> Still here: Wayne, Eric, Shadi, Shawn, Kevin, Brent, Melody, Sharron, Brent, Melody

Wayne: Yes I tried the techniques recommended in the tutorial and it is not acceptable to those with low vision. There is no way to let people know it is there.

Shadi: Did we not discuss this last week?

Shadi: what do we do about it? It is now a w3c recommendation. Several browsers do not implement it, similar to MathML. Not implemented but theoretically a good solution. Could add a note in the tutorial.
... Eric looked at your workaround, the problem is that it is not simple and needs Javascript to work and is fairly inelegant.
... is the note OK or are you looking for more?

Wayne: I am looking for something that takes less than decades to work. Let's take a good look at the Note, it will be an important note. The techniques for low vision are nowhere within these tutorials. I am discouraged.

Shadi: So making it specific to the tutorials?

Wayne: Within the tutorials can we note whether techniques are useful for low vision? Can there be a specific workaround for this situation?

Eric: We have a few possiiblities, they will take some work. We can make a polyfill for that tutorial to say this is how we imagine longdesc will work if properly implemented.

<shawn> [ Shawn thinks thats' out of scope for this Tutorial]

Shadi: The PF working group does nothing else but create code libraries for accessibility. But we need to keep in mind what we can do within the context of the tutorials - do we have the bandwidth to do this?

Eric: The other option is a note without specific code workarounds.

Wayne: The truth is I think the tutorials is just the place for this but it may be too late. It is best practice on top of WCAG. When we are aware of something that is a problem for 2/3 of people with visual impairments, and we have a code solution and we do not present it, we are not doing it right.

Shadi: There were several places in the tutorials where we were confronted with evolving technologies, lagging browser implementations, etc. What we have done before is to describe the issues and pointed to exisitng polyfills or solutions in the world.
... what we have not done is to develop and maintain new solutions ourselves.

<yatil> http://w3c.github.io/wai-tutorials/images/complex/

Shawn: We all agree that we need to communicate that this does not work in current browser implementations
... how do we address that in other cases?

<yatil> http://w3c.github.io/wai-tutorials/images/textual/#mathml

<shawn> Note: The long description linked by longdesc is reachable by all users in

<shawn> Firefox. There is an official Chrome Extension that adds long description access. In other web browsers, longdesc is only available to

<shawn> screen reader users at the moment. There is currently no support on mobile platforms.

Eric: In MathML we called out the lack of support in the side bar, we could increase the visibility about longdesc as well.

Shawn: Could add more emphasis, move it to the sidebar

<yatil> In other web browsers and mobile platforms, longdesc is **not available to anyone**, but screen reader users at the moment.

Wayne: There are approaches that I use becasue they are accessible to everyone. The one that limits access for many people is the very first one.

<shawn> [ Eric - I think the beginning of the note needs to be more clear.]

<shadi> +1

<yatil> [ Shawn, OK ]

Wayne: the second one is more widely available, as is the third. So putting a visible link to a longdesc allows access by all, the first solution listed limits 2/3 of the people who need it.

Shadi: To summarize: We are in agreement with the Note, making it more prominent, more clearly explained, more options listed, and perhaps changing the order.

Shawn: And point to the most accessible solution on that page

<Brent> (note for minutes) leaving sub-group meeting now - Bye

Eric: The question is what do we want to recommend. at the moment it doesn't work well for anybody. But if it is not longdesc, due to bad support, then we should promote one of the others.

Shadi: No, we should use longdesc and promote its use.

Shawn: Yes we should say use longdesc, but it is not widely supported so in order to meet user needs you must also add another solution.

Sahdi: also need to say what longdesc is intended to do and distinguish it from describedby

Shadi: Next step is for Eric and I to propose wording and get it to you before we open the survey.

<shawn> this makes it clear that yes, longdesc is a good solution; however, need workaround now. maybe then developers will pressure browsers to support it better!