<Sharron> Scribe: Sharron
<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.
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.
+1
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!
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/They/Laura and Nic/ Succeeded: s/(Briefly stepping away. BRB.)// Succeeded: s/(I'm back)// Succeeded: s/teh database/the tools list/ Succeeded: s/Wordsmithing/Avoid wordsmithing now, just two points if need more input:/ Succeeded: s/EOW folks/EOWG folks/ Succeeded: s/Remve/Remove/ Succeeded: s/ahve / have/ Succeeded: s/ahve/have/ Succeeded: s/chnages/changes/ Succeeded: i/Shawn: That means we could hav/Vicki: I tried to pull the content out of the presentation in case the presentations would go to phase two. Succeeded: i/Eric: I looked over Shadi's edits/scribe: Brent Succeeded: s/Vicki AWESOME!/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!/ Succeeded: i/Shawn: That means we could have/scribenick: yatil Succeeded: s/@@@@ GRAND PLAN @@@@/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/ Succeeded: s/buttons that we already have/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./ Succeeded: s/in the navigation to go from slide to slide. Would be great for self-learning as well.// Default Present: Jesus_Pulido, Sylvie, Brent, Shawn, Laura, Norah, Robert, Shadi, Sharron, Vicki, Roy, Howard, James Present: Jesus_Pulido Sylvie Brent Shawn Laura Norah Robert Shadi Sharron Vicki Roy Howard James Regrets: Nic James Chris Amanda Andrew Stephane Kris_Anne Found Scribe: Sharron Inferring ScribeNick: Sharron WARNING: No scribe lines found matching previous ScribeNick pattern: <yatil> ... Found Scribe: yatil Inferring ScribeNick: yatil Found ScribeNick: yatil Found Scribe: Brent Inferring ScribeNick: Brent Found ScribeNick: yatil Scribes: Sharron, yatil, Brent ScribeNicks: yatil, Sharron, Brent Found Date: 08 Dec 2017 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]