WCAG-EM report tool

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

Sharron: May I just say "Bravo!"...reporting tool, where have you been all my life!? But I understand that my perspective is one that has been steeped in this stuff for so many years. I am really interested in hearing the reaction of someone who approaches with beginners mind.

Helle: like me

Shawn: Jan's would be good perspective

Shadi: We are wrestling with the fact that there actually are certain required skills before this can be used effectively. It is still an early prototype with bugs, etc, but wanted to present most of the planned functionality. We want EO's feedback at the general approach, usability, structure, steps, how they are labled. We will add some guiding text, but want to try to keep it to a minimum.

<shawn> [ Website Accessibility Evaluation Report Generator, WCAG-EM Report Tool, or other?]

Shadi: you should follow the link to find the starting page. This is the starting point for the process. The text will say that this tool helps generate reports based on the WCAG-EM, will help you gather data to create a report. It is NOT an automated tool in any way, it does no evaluation.
... there is no data saved here although there is a function that allows you to save locally and return to an evaluation in progress
... you can import data from a previous section using the "load data" function
... the progress bar shows you your current place in the process and you can move among them.

Helle: I was curious about how to save data if you can't complete in one session. Will it ask you to load data or will it find the data on your local machine?

Shadi: There is a session saved in your browser, saved in the cache. If you close your browser before you return, you will lose that data. If you have added a lot of data and somehow leave the page but leave the browser open, you can return and it will be retained. To permanently save it, you must choose a local folder in which to do it.
... whenever you start a new report, all the data will be cleared.

Helle: So if you have wierd systems like we do where you lose Internet connectivity or the browser crashes, will you lose data?

Shadi: If you lose connectivity your browser will save the data. But if the browser closes, the data will be lost.

Andrew: Maybe we should have a "load data" 'button' beside the "start new evaluation" button?

Helle: Is it possible to save data as you proceed through?
... somehow we must tell people to be very aware of their data as they go through.

Shadi: Yes, there is a "Save data" function and we can remind people to do that if they have an unstable connection. The question is should we have a separate button to say "Clear data" rather than "start a new..." Would that make it more clear?

Helle: "Continue" is good for me, but people must be informed that they can only work on one at a time and that data will be cleared if a new one starts.

Andrew: Suggest moving the save data button near the start a new evaluation button to make it more clear.

<yatil> +1 for Resume

Shadi: I like the word resume for the continue function and perhaps emphasize that data will be cleared.

Andrew: Yes it is improtant to give that reminder that when you start anew, it will clear existing data. Text must be very brief but should provide the needed guidance.

<shawn> + to intro text being brief but clear. think will need headings

<Helle> + to Shawn

Kevin: It might be beneficial to prompt that there is data that will be cleared so that they understand that they are doing that. Affirmation of the understanding.

<Andrew> +1 to kevin (if practical)

Sharron: +1

<shawn> +1 to very little text by default and the (i) showing more info

<AnnaBelle> +1 to shawn's comment re very little text

Shadi: I usually don't like those "Are you sure you want to start a new..." but in this case it may be useful to do.

Shadi: OK, let's click ahead and choose "start a new evaluation" which will take you to the set up page. There may be a bit of text - don't want to include too much. The fields all have an information icon that will pop-up with info from WCAG-EM. There are terms derived from WCAG concepts of accessibility support and familiarity with those concepts will be supported.

<Howard> I like the example

<kevin> +1 to Howards ticks

Shadi: there are some pre-filled example text. If you come to fill-in the text box, the dummy text will disappear. Another option is to have a prompt rather than dummy text. We chose to provide an example since there is guidance in the info icon widget.

Shawn: I like the default data but it must be clearly differentiated so that if I leave a field blank, if the dummy data is saved, it is clear that it is not part of the actual data that is saved and reported.

Sharron: Can you not script it so that dummy data is not saved?

Shadi: Yes it is only visible as long as you don't enter anything.

Andrew: hence the suggestions of brackets or other indicator

Shawn: it would be nice to be able to easily tell what I have completed. When skimming it is hard to tell which are still to be filled in. If I am skipping around and don't get to one, how will I know I have skipped it easily and quickly.

Kevin: One of the difficulties, if there is text there, it is very very easy to miss the fact that you have not provided content. Audits may run over multiple dates and wondered about how that is identified with only one date?

Shadi: Usually the date is when you submit or complete the report. We will address that point later, let's continue with the question of how to clarify the difference between dummy data and actual data?

Andrew: I agree it a bit confusing. If you tab in and out of the dummy data it remains within the field.

Eric: We have the HTML5 placeholder and there is no indication yet of required fields. the placeholder attribute will keep the data from being reported and retained.

Wilco: My main concern is accessibility support for the placeholder attribute

Eric: Yes, it is safe to use.

<shawn> [ Shawn not convinced that it should disappear with focus]

Shadi: if you have data that disappears when tabbing into the form, screen reader users would not have access to it.

Wilco: The info icon could also contain the prompt

Helle: Do we actually need that dummy data?

Shadi: That is a question back to you..is it useful? helpful? more clear?

<Andrew> on this page, dummy data not required IMHO - why not use the "i" info more?

<shawn> +1 to example data being in the (i) info pop up (Wilco's idead)

Helle: If I go through the app, I can see that it might be helpful, but perhaps after you ahve explored, you have the option to clear all dummy data.

<AnnaBelle> I like the dummy data, though there is rather a lot, e.g. in "Accessibility support baseline"

<Zakim> Howard, you wanted to offer possible solution to dummy data problem - put a green check box as each field is completed

<paulschantz> This UX article about hints inside text boxes is worth looking at (so are the comments): http://www.uxmatters.com/mt/archives/2010/03/dont-put-hints-inside-text-boxes-in-web-forms.php

<metzessive> thinking out loud. Can you have a button that would fill it with dummy data/ clear it?

Howard: One possible solution is to put a check mark that affirms that you have filled in the form. I think the dummy data is very helpful however, especially for those who are seeing it for the first time

Wilco: Could provide it as an option - with and without dummy data

Shadi: You're saying that this is helpful. Would it be as helpful if in the icon instead?

Howard: From my POV, it is better to have it right there, don't have to take the step to open an info box

<Zakim> shawn, you wanted to comment on this point - examples in info boxes - could have button to show them, but I think not worth the complexity

<Andrew> this is more a tool for experts - should need too many hints as they shouldn'thave already read WCAG-EM

Shawn: Whether or not we provide the examples as text in the info box or as a button "show me dummy data" may be worth considering. May add too much complexity.

<Andrew> no dummy data

<Howard> yes to dummy data

<Andrew> no dummy data - put in (i)

<Helle> in the info box

<AnnaBelle> yes to brief dummy data

<yatil> Dummy data standard behavior, having it in a placeholder attribute, prefixed by e.g., disappearing when entering the field.

<paulschantz> +1 to yes keeping dummy data, but ONLY if it disappears when entering the field and is NOT submitted as default entry

<shawn> no dummy data - put in (i)

<kevin> yes to dummy data as placeholder

Sharron: I am not sure about it yet

<metzessive> No dummy data.

<Andrew> if use placeholder attrib, then should also put in (i) for reading later too

Sharron: I tend to agree with Andrew that it is a tool for experienced accessibility folks and should not need excessive examples

<shawn> +1 to Andrew to have it in (i) no matter what

<metzessive> I like the idea of having it in (i), actually

Shadi: Accessibility support is an issue. Not sure we can make the data much clearer but we may need to make it more brief. It may be helpful when popup data is more developed
... It would be good to put that data into the info box in any case.

<AnnaBelle> I take Shadi's point about my example, but I can find other examples, so in general briefer (which is hard, I know)

<shadi> agree AnnaBelle, and I will take a pass at that.

Andrew: In terms of helping people who are not entirely familiar with WCAG-EM, can we provide links to relevant sections of the resource and to WCAG itself? I also wanted to note that sample text doesn't disappear for me

Shadi: Yes we want to look at that possibility.

AnnaBelle: On the cover page, there is an item I will email the group. Utterly awesome initative - wonderful!

<kevin> +1 for awesome

<Andrew> +1 to Anna Belle's excitement :)

<Helle> +1

AnnaBelle: I tried to work my way through an example, I wondered what was happening at the other end. Who is looking at, has access to this data? Need a clear explanation of that.

<Andrew> good point re privacy statement

Shadi: Yes, good point about the privacy notice, need to make it clear.

Shawn: ...and can we have a progress link in the footer, etc to show which steps are done?

Shadi: Shawn, what was your comment about the progress steps?

<Andrew> nice idea

Shawn: It would be nice if I can tell what I am done with. I think it is great that I can go in any order, but need a checkmark or something to indicate what is done as well as how I am in relation to the steps across the top.
... it could be in the navigation itself or on each page or something.

<paulschantz> completion bar

<Andrew> and yes to manually saying 'done' (not automatically)

Wilco: A complete this step button and skip to next step button

Shadi: Unless you feel this is critical, I would like to make this a future consideration. Especially in step 2,3,and 4 there is a back and forth that goes on that adds considerable complexity
... right now, the progress bar highlights the current step, should we also change status on completed pages?

Shawn: no need to add that complexity right now.

Shadi: Onward, Step 2 there are now going to be more complex widgets where you start looking for specific technologies, provision of data, etc. Step 3 adds pages for the sample. In the final, we will probably only have just 1 example of dummy data. We have fleshed it out for you consideration, but won't be this way when final...

Andrew: Rather than reducing it to just one page in the example, the fact that many sites have commonly used features and we may want to populate with those. as well as prompt for sample pages that are suggested by WCAG-EM

Shadi: But that would necessitate the removal of those pages if not part of the site being evaluated.

Andrew: I was expecting that it would randomly select the pages for me.

Shadi: We are hoping that we might be able to import from other tools where the random selection may be made for you, but not yet.

Shadi: Step 4 is the most complex. it is where, now that you have made the selections, you actually perform the evaluation. You can mark SC as failed for the entire sample for instance, as you see in the dummy data for 1.1.1.
... However you may also report page by page where failures occur in some pages but not others, etc. So let's say you are working on just one page, then just that one will be filtered for and data will be provided for only those that are selected.

<yatil> +1 for "Show results for individual pages"

Shawn: This would be good to have informal usability testing on. Functionality is awesome but I would not have figured it out without your explanation. For one thing, the levels do not need to look like buttons. And saying "show individual evaluation details" is fine but it needs to be more clear what the "individual" refers to - is it page? pages? SCs or what?

<Andrew> maybe "show/hide eval page details"

<Andrew> prefers only 'show' on each SC (no 'show all')

<Andrew> like expand/collapse on guideline level (at the moment)

Shadi: Show all/ show only certain SCs/show certain pages, need to figure out how to make it clearer. It is organized by Principles, Guidelines and SC. Should we expand/collapse

Shawn: I am curious about everyone's perspective. This is the meat of what you are doing. It is organized by SC rather than by page. If you are evaluating a page at a time, how does this feel as a way to organize the data?

Shadi: The reason we have it organized this way is that it matches the report format.

Paul: I love this page, it was immediately understandable to me. I would add to the left filter options to select all / select none

<Andrew> SC org is prefered by many here (rather than page organization)

Sharron:Well, I am more accustomed to thinking page by page until patterns begin to emerge. But I think can get used to this. when reporting and summarizing you do that by issues and pull examples from the page-by-page data.

<Andrew> you can still work page-by page - just select a single page on LHS

Kevin: There are a couple of things, the structure of the Step 3 page and the other is about the presentation of the SCs. It is a huge long page and might be better chunked up by Principle and make it more managable, less overwhelming on first look.
... my approach is to a general overview and then go page by page. When I first saw the page, I was stumped. Could not understand how the examples related to the SCs and as I explored, I got even more confused.

<shawn> +1 to expand - collapse or somthing on principle level

Shadi: Running out of time. Can people enter in the GitHub or wiki/email comments and circulate these ideas and impressions. How this does/does not work for you and especially how it can be improved.

<paulschantz> Instead of "Sample to Evaluate," header could read "Filter Sample"

<shawn> for little fixes: wai-eo-editors@w3.org OR wiki

<paulschantz> agree with taking it to email

Shawn: So send those big ideas to the EO list and small fixes to editor's list

<shawn> for things to discuss and ideas to share: w3c-wai-eo@w3.org

Shadi: Yes, the wiki is not so good for discussion. Send these formulatic ideas about organization, approach, etc to the EO list

Howard: I suggest that one thing that might help is to show pages that are being evaluated and what the results are referencing. If the pages being included were checked by default. and perhaps an option to show page by page results.

<Andrew> +1 to Howard re show all selected if that is the default

Shadi: Overall is this the basically right approach that needs refinement or do we need to entirely rethink the approach. If this is more or less the right approch but needs clarity, please suggest things that will amke it more clear, please send suggestions for how to make it more clear.

<paulschantz> concept is sound

Paul: I may be alone here, but I grokked it right away but think that you could describe it better. I think it is an extremely useful way to approach it. You may have systemic problems across the site but may want to filter out the ones that have huge problems to separate for later consideration.

<Howard> +1 to concept

<AnnaBelle> +1 to Paul's grokking :-)

Shadi: Wilco's issue was why to add the same issue every time and are looking at a macro way to add something like contrast that fails on every page.

<Andrew> it's easy to copy/paste

Shawn: We can discuss again next week. It is hard to tell what is the intended functionality vs what is still in draft. Do you want to tell us any of that now or save for next week.

<Helle> +1 Wilco's idea

Shadi: You may not want to fill out everything for every page. If it fails once, the sample fails so the additional data may be needed for other reasons but does not change the fail staus of the sample. That is not our call.

<Andrew> a blanket 'fail' is not useful to a site owner

Shadi: there will be another function that adds that failure or success state to all pages, but has not been implemented yet. There is quite a bit of functionality still to be added.
... Step 5 is the wrapping up step, add the title, the commissioner, the date, the evaluator, etc
... then an executive summary for the report, all from WCAG-EM and the ability to refer to the data that was collected.

<shawn> [ Shawn encourages EOWG folks to both: review it by looking at it, AND try actually using it to evaluate for flow, etc. ]

<Andrew> suggest adding show/hide on detailed audit results to minimise scrolling

Shadi: if you have decided to provide data for individual pages, it will be available in the report. When you generate the report it is displayed and then when you download, you get the HTML and if you want data, you must save that as well.

<Andrew> if a SC is 'not applicable' it should not shown results page

Helle: Shouldn't those items disappear from the list if they are irrelevant to the site, for example video, should that not be dropped?

Wilco: We are considering for the future to be able to customize the report, possibly to show only those that pass or fail. But for now we show all the data and of course, the evaluator can download and customize. We may add more customization later on.

Shadi: Thanks for this good discussion and valuable feedback.

<paulschantz> amazing work! Kudos

<Andrew> +1 to paul - excellent work guys

Tutorials

<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2014JulSep/0025.html

<paulschantz> this weekend

Shawn: Remind everyone that we wanted your approval by July 31. Thanks to Helle for doing it. Now need everyone else to complete.

<Andrew> this weekend too

Shawn: Paul can do it over the weekend, Andrew as well. Jon since you we not involved in their development, you are welcome to just take a pass on it or you can review and comment if wanted.
... our hope is not to get any major changes and to publish as soon as we can.

Planning for Web Accessibility

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

Shawn: Kevin, I am sorry that we have so little time left. Can you briefly walk us through what you did and what you need from us next.

Kevin: I focussed on the structure, moving Buy-In up earlier in the process and so put something before the policy that helps define the drivers, and getting that executive level buyin. Cleaned up Roles and responsibilitites, more tightly focuesd, talkingless about job role and more about functional roles. Taked specifically about smaller and international orgs.

<AnnaBelle> Wow, Kevin -- you've done a ton. Thanks so much!

<shawn> +1 for pulling stuff out of intro into separate section

Kevin: started now to work on Developing Organizational Policy. In terms of focussed questions for the group, does the structure make more sense now, is the general tone correct, do they work well together?

Sharron: defintiely showing more focus and clarity , good work. And are we trying to integrate other related docs at this point?

<Andrew> +1 from me too :)

Kevin: The immediate aim is to review the 3 central documents as well as Start with Accessibility, dust them off and update them. The longer term goal is a tool to guide people through the process.

Shawn: A more interactive tool that will expose the information that is most relevant to you.
... depending on your role

<Howard> I like the structure & organization

Shawn: what about the refined approach the fact that for each section there are these defined sections. How is that working, what are next steps?

<shawn> [ minor point: the Example responsibilities box has too much visual attention ]

Sharron: Are these steps listed in the first section going to be relevant to all sections?

Kevin: No not necessarily.

Sharron: Will there be constants in each section?

Kevin: Yes there is meant to be a consistent structure so people know what to expect. They could grab a particular part and run with it.

Shawn: So in the first part, the particulars might be listed within the Discussion. I am a big fan of headings for skimming and text for detail, not sure about the visibility

Kevin: Where there is value in exposing the headings, I am in agreement.

Sharron: Good tone, succinct

Howard: I thought it would be nice to have case studies, examples of how this organziation accomplished what they did.

Sharron: +1

<Andrew> don't hold up for case studies (though nice to have if volunteered)

Shawn: We worked hard to get case studies to build the business case and should try to invite, through WAI-Engage or somewhere

Sharron: People are more likely to brag these days

Howard: Looking at conference presentations could get some likely candidates

Andrew: Different from talking at a conference than writing it up for WAi

<shawn> Wiki <https://www.w3.org/WAI/EO/wiki/Feedback:_Implementation_Plan_for_Web_Accessibility>

Kevin: For next steps, I will continue working through fleshing out the sections, will be happy to consider comments

Shawn: So folks can look at first 3 sections, big picture things, tone, no need for wordsmithing yet.

<Andrew> suggest including an action plan possibility in the 'project life cycle' section (probably there) that includes addressing access for people having difficulty while the site/app is being improved

<metzessive> thanks! Bye!