Education and Outreach Working Group Teleconference -- 08 Dec 2017

<Sharron> Scribe: Sharron

Selecting Evaluation Tools

<shawn> Requirements (docx file) https://lists.w3.org/Archives/Public/public-eo-plan/2017JulSep/att-0023/plan-outline-selecting-web-accessibility-tools-PlanningFeedback.docx

<shawn> Revised resource https://w3c.github.io/wai-selecting-eval-tools/

Brent: There are links to look at the versions and the diff file. Then we have the questions that need to be answered. Laura and Nic have tried to align the document to the Tools list and also couldbe used as a stand alone document.

Laura: I think Brent has introduced it all quite well and I am ready to discuss.

Brent: Has everyone read the requirements, etc? If so, we can move through the questions. Otherwise take a minute to look through them...

<j-pulido> Done.

<shawn> done

<Vicki> done

<rjolly> done

<yatil> done

<Sylvie> Done

Brent: So let's look at the questions, one of the purposes for the revision was to align with the tools list while ensuring it can also stand alone. Is this document doing that?

Robert: I think it is fantastic. It can stand on its own, it's clear and concise and may need to be more prominently linked to the tool. I did not see the disclaimer that was in the outline.

<j-pulido> +1 Concern about the word disclaimer being used only in the Proposed Outline section

Shawn: The disclaimer should be covered in the "what to expect" section and was not planned as a separate statement.

<Vicki> +1 for the whole document. Very well done.

Robert: OK that seems good to me and just wanted to be sure it was not planned as a separate call oout.

Brent: The disclaimer was meant to address the question that W3C does not endorse tools, is that right?

Robert: No tools are mentioned here, so that may be a statement for the actual Tools list.

Eric: That's right, on this page it was more a disclaimer about how human judgement is always needed and that testing cannot be 100% automated. I think that is covered in the paragraph here.
... what I see in the More Details section there is an authoring tools bullet, seems the second sentence should be promoted and leave out the first one.

<Vicki> can't hear laura

Laura: I think he is saying to remove the first sentence since it refers specifically to the Tools list.

<shawn> proposal - delete "Lists which authoring tool the evaluation tool integrates with. "

Laura: Does everyone agree that we should take that first sentence out of the authoring tools bullet?

<shawn> [ Shawn sees other places, too "Lists the browsers for which a plugin exists, if any. " ]

Laura: So this is where the question becomes do we need to re-write the whole document.

<shawn> Brent: ... also "Lists the report format(s) the tool generates"

Brent: You are describing here what happens when you use the filters in the Tools List.

Shadi: You can only search for authoring tools that can be plugged into so the distinction between what is and is not searchable is made. I like the direction this is going since the filtering aspect is key.

Shawn: But is it confusing if you are not looking at the tools list?
... if someone is just trying to learn about the different features to look for in tools?

Laura: We are trying to do two things here, this way it makes sense to me -?-

Brent: What if the first sentence is moved to the end of the paragraph and references that in the Tools list, selecting this filter will show plug-ins or something. Would need to be reworded but the info about authoring tools in general comes first and the tie-in to the Tools List comes after that.

<shadi> +1 to brent

Shawn: Not sure it is necessary. I agree to take it from the beginning but not sure it needs to be added at the end.

Brent: Something like "the following can be filtered for in the tools list" Could then remove the following sentences.
... Trying to give general info as well as support the tools list. 3 options: Can remove the leading sentences entirely, could move them to the end, or could make one sentence at the top of the section saying you can filter for these features in the Tools List.
... any preferences/objections?
... shall we then let Laura and Nic choose which direction to take?

<j-pulido> I think it's probably fine where it is, but Laura/Nic can decide

Sharron +1 to editor's discretion

<rjolly> +1 to letting them make the decision

Shawn: I support that.

<Vicki> +1 to editor's discretion

<shawn> +1 for editors' decision on removing "Lists the..."

<yatil> +1 for editor’s discretion

Laura: And Shadi how are you feeling about that?

Shadi: I see so many improvements since the last time, I can see you and Nic have been working really hard on this thank you
... I know it is a hard balance, helping people understand what Evaluation Tools are in a general way while alos making it a user guide for the Tools List. Thank you for the progress on this, it is really coming together.

Laura: I just wonder if you have a preference on which option to take?

<Sylvie> Also +1 to editor's discretion

<Zakim> shawn, you wanted to comment on "But we cannot check all accessibility aspects automatically." and to comment on "Human judgement is often required."

Shadi: I have posted a few pull requests, a suggestion is to describe the feature and then to show how to do that in the Tools List. Making it more clear what the feature is first and then showing how to do it in the list.

Brent: Sounds like Shadi recommends 2 or 3

<j-pulido> +1 Concern about the "But we cannot check" and "Human judgment" sentence

Shawn: Avoid wordsmithing now, just two points if need more input: - "But we can..." may need to be reconsidered "but" in general and especially at the start of a sentence. Also "Human judgement" not often but always.

<Vicki> +1 remove But, and remove Often

<j-pulido> Also, "Judgment" is spelled wrong

Laura: "always" seems strong.

Shawn: Agree but could simply remove "often" and not replace.

Brent: Once these changes are made, it is ready for Thorough Review. Agree?

<shadi> ACT TF

Shadi: Yes agree about this and do we want to ask for input from ACT Accessibility Conformance Testing Task Force. and maybe others? At what point do we bring them in?

Brent: Good suggestion, will discuss in planning
... meanwhile, editors will take your suggestions, make another version for final review.

Eric: I want to encourage everyone to do the review ASAP and before final approval so we can expedite the processing of documents and get content finalized for new site. Want to avoid many comments in the final review, want to get them addressed quickly and soon.

<shawn> +1 for EOWG folks commenting asap now

Laura: When I make these changes in GitHub, I should simply edit the document?

Eric: Yes, edit and commit and chages are saved.

<shadi> [I *love* the new design!!!]

Laura: Great, thank you

Brent: Fantastic job on this resources, thank you so much for the hard work and back and forth on this.

Diff versions

Brent: With these revised documents, our expectation is that people understand that the entire document does not need to be reviewed, only the changes. These are mostly previously approved documents so when possible we will try to provide diff versions so reviewers can focus on those changes.
... Shawn will show the way to do an HTML diff although sometimes it is easier to do another kind of diff when the new site design is involved.

Shawn: In Word, drag and select and copy the main content of the page you want to compare. Paste it into a new Word doc, save. Then look at the new version, do the same, copy it into another new Word doc, save as "new". You should now have two separate new documents, go to the Review tab, select Compare

Brent: It is extremely important to get the old in "original" or you will get it the other way around.

Shawn: If you are sharing this with others, it is nice if you can clean it up a bit. Remove formatting changes and other superfluous changes to remove clutter.
... can add headings back in etc to help people who will review
... can add comments if you want specific kind of feedback
... In some cases there are significant changes and it may be better to just read the versions and not try to do a diff. But where there are few editorial changes, this is cnveninet and the reviewer can jump from one change to the next easily.
... Also can generate an HTML diff, it works if you have just a few changes, it is on the W3C site https://services.w3.org/htmldiff

<Brent> www.copyscape.com

James: There is copyscape.com that shows a diff version as well.
... good visualization of the differences.

Brent: any questions? If you are an editor, if you haveany problems, ask for support from planing team.
... WrapUp
... will have the weekly survey, trying to get feedback on Face to Face meetings so please complete that as soon as possible. Survey open for HPWDUW, there are significant changes, need people to complete the survey and remember that you can answer that you did not have time to complete the review, just be sure to respond.

<Laura> I can get to them today.

Brent: will hope to have the approval survey for the Selecting Eval Tools this week
... with no more comments or questions, we will now move into a smaller meeting. All are welcome but specifically the editorial team for the Older User resources should stay.

trackbot, end meeting

<trackbot> Meeting: Education and Outreach Working Group Teleconference

<trackbot> Date: 08 December 2017

<yatil> scribe: yatil

<scribe> scribenick: yatil

<shawn> +1 to Vicki leading ;-)

Vicki: Thanks to shadi for editing the slides. Let me look with different eyes on the resource.
... First main question: Can we keep the revised version as done by Shadi?
... Do we keep the old version AND the updated version?

<shawn> +1 to having new version and old version as archived

Shadi: We would archive the 2010 version and mark it archived.

Vicki: I don’t think we have a lot of time to work on the slides and they would be a task for after the redesign.

Shadi: And the new site would have the 2017 version of the slides
... we have the HTML and would need the powerpoint version.

<inserted> scribe: Brent

Eric: I looked over Shadi's edits, I have hesitent presentational wise putting this on the site. (Not talking about content but presentation).
... Also, if we are updating the slides, do we really need to archive the old ones, instead just point to the updated ones. Could be distracting for users.

Shadi: Content wise, this seems to be more stable. What you are referring to is the more visual design. I am not sure how the redesign will address the visual appearance of the presentations.

Shawn: Presentations was held for phase 2.

<Vicki> https://www.w3.org/WAI/EO/wiki/Web_and_Older_Users

<inserted> Vicki: I tried to pull the content out of the presentation in case the presentations would go to phase two.

<inserted> scribenick: yatil

Shawn: That means we could have the same information as a page instead of the slides.

<shawn> word file https://lists.w3.org/Archives/Public/public-eo-archive/2017OctDec/att-0023/Ageing_and_changing_abilities.docx

Shadi: I wasn’t aware that the presentations are in phase two. If we have a different way to present it, like a page or a set of pages it might be a better way until the presentations can be updated for the redesign.

Shawn: Two reactions: Looking at it standalone, I thought it was a good idea, but then we’d need to have a temporary page for the interim.
... Would we want to have a separate page in the end? Or just a presentation?
... If we had all the time, would we still want a separate page.

<Norah> +1 to html page

Shadi: I think I like it, having a page and then say: Here is a presentation for this page.

Vicki: Someone looking for this information might not look at an presentation.

Shawn: So maybe we want to have it on a page anyway.

Vicki: I would want to do a plain search on the site, but I don’t see presentations as the primary source for information. Might also surfacing information better.

Norah: I agree, information in presentations is easily missed. I had the mindset that the presentations are other versions of the content available on the website.
... I wouldn’t expect new information in the presentation.

Shadi: Just to clarify the info is in the literature review, but this is the distilled version.
... so it might be the better approach anyway.

Norah: I haven’t looked at the presentations a lot, but I prefer the HTML

rjolly: When people come to look for presentations, the plain HTML tersified stuff is great. Is the historical use of presentation for giving people information to put in their decks.

Shawn: ... yes.

rjolly: I like when it is on the website but I also like to have presentations as well.

shawn: and that’s what we plan to do.

<Vicki> cool

<Vicki> eric the guru

<shadi> eric++

<shawn> Eric will do that over the Dec break ;-)

<Vicki> eric+100

<Vicki> yay, i'm a passenger. all too exciting

<Zakim> shawn, you wanted to ask about separate page versus expand collapse on existing page?

Eric: My vision is that we have slides or slide sets for each page. The question is: As many people don’t just take slides but copy and paste them into their own slides, wouldn’t it be a good to have multiple pages with the slide content on the top and context below it. It would not be meant for presenting directly but to explore and inspire people for their presentations. Then we could use our previous and next buttons that we already have on the bottom of the page to go from slide to slide. Would be great for self-learning as well.

All: That sounds like a great idea (on an infinite time scale).

Shawn: What if we would use an expand/collapse for now?

Vicki: If it works and looks OK, it might be a good avenue to persue.

Shawn: When we think MVP, we might want to try it out.

Vicki: That makes sense.
... Back to the presentations page: Little links to it.

Shawn: We have to determine how we want to handle links to old pages.

<Vicki> https://w3c.github.io/wai-older-users/older-users/

Vicki: I like the bizcase. Can we add a couple of pages on the left?
... I liked the short landing pages and multiple other pages.

+1 to same style.

scribe: I think the way different resources are built should be similar overall.

<Vicki> https://www.w3.org/WAI/EO/wiki/Web_and_Older_Users

scribe: I want to add overlapping… and other aspects of the new page lean themselves to have their own page.
... Technical resources might work for it.

Shawn: We have to look into what is on the page, there are different resources on the page. Some are sub-pages and others are not. You only want sub-pages on the left.

[ Eric: Only sub-pages _can_ go into the left, technically :-D ]

Vicki: That makes absolute sense.
... Another question on the footer of the pages: Putting the WAI-AGE in the footer.

<Brent> Does each page have it's own footer aside from the site footer?

https://w3c.github.io/wai-website/test-evaluate/easychecks/

<shawn> Yes, Brent, each pages has it's own footer

Shawn: We will generate the footer from metadata on the pages.

<shadi> vicki+++!!!

<shawn> Shawn: Thank you so much Vicki for thinking through the options and for the clear presentation of ideas for us to consider and decide on! Awesome!

Vicki: I will make the changes and we should make it to the review next week.

<Vicki> ;)

Everyone: Kudos, Vicki, great work!

- DRAFT -

Education and Outreach Working Group Teleconference

08 Dec 2017

Attendees

Contents

Selecting Evaluation Tools

Diff versions

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output