EOWG convened to discuss progress on current deliverables and plan for wrapping up the year. Brent reminded the group that there would be only this meeting and one more. He asked the group to attend to surveys and expect full agendas for the next couple of weeks. Kevin reviewed his progress and expectations for the the Planning and Managing Accessibility resource. He is planning to have a complete first draft by next week for review over the year end holiday break. Eric introduced his current work on the QuickRef and the following resolutions were made:
Brent: Reminder we have only this meeting and one more this year so expect a full agenda this week and next, thanks to everyone for attending and contributing.
Kevin: Survey results for how to handle the more info links
<kevin> https://www.w3.org/2002/09/wbs/35532/EOWG04Dec2015/results#xq2
Kevin: in general the preference is *not* to leave links to more info inline. Even those who had another preference it was not strong.
... may need to think about the heading, will revisit after the break. Any concerns with that approach?
<shawn> +1 to that approach
<Brent> +1
<Andrew> +1
<AnnaBelle> +1
<Howard> +1
<yatil> no concerns :-) +1
Kevin: fyi, several changes to the Initiate section, one still open related to Overview pages.
... any questions on that?
Brent: Have been working on Initiate changes, will close that up and we will be able to review this section again when we perform the final review of the entire tool. For now you are asking for just a preliminary look at the section?
Kevin: Yes
Shawn: Reminder that this is the first review, then we will do a thorough review of the entire resource, and then a review to approve publication.
Kevin: Intro and first review of Plan section will be available this week and comments will be welcome then.
Sharron: aOur goal is to have at least a rough draft of the full resource by the time we break for the holiday.
<kevin> http://w3c.github.io/wai-dynamic-planning/plan/
Brent: any other comments and questions about this resources?
<yatil> https://www.w3.org/2002/09/wbs/35532/EOWG04Dec2015/results#xqr4
<yatil> https://github.com/w3c/wai-wcag-quickref/issues/76
<yatil> https://w3c.github.io/wai-wcag-quickref/
Eric: We discussed this last week and if you look at the prototype, we link to a section on the bottom that talks about the techniques. Tried it at the top with expand collapse but it did not work well.
... you may want to review
Brent: Comments about this proposal for addressing the need to explain Techniques, please take a look and offer your opinion of this solution.
Shawn: I wonder if there is room to put one line in the top, for important information about techniques...link. I would suggest that. I don't really love that it moves down to the bottom. Probably OK because it will only happen once.
<kevin> +1 to not liking the jumping
<shawn> [ note to Eric - that the link is working for me in Forefox, but not Chrome ]
Brent; Everything on the page stays the same, you just move to the bottom?
<Andrew> +1 to not liking the jump either
Eric: Yes and to return where you were, you use back button.
Shawn: I would not know to do that, would expect going back to a new page.
<shawn> [ actually, back button does not work for me ]
Andrew: What about a pop-up?
Eric: Personally I don't like it, focus management etc. Will do what the group wants.
<AnnaBelle> I prefer jumping and not a modal window.
<yatil> [ note to Shawn - Works in Chrome for me... Will investigate... ]
Andrew: Someone mentioned that people are likly to use only once which is true.
Shawn: What about an external link?
Howard: I experienced it OK, it did not bother me to jump but trying to go back up was a surprise how long the page was. Using the back button is OK and the fact that it would be used infrequesntly.
<shadi> [[Note: Other techniques may also be sufficient if they meet the success criterion. LINK See note on techniques /LINK ]]
<shawn> -1 to linking "other techniques"
Brent: What about showing text when you click the link and add Hide at the end of the exposed text?
<shadi> [[ that is, highlight the link separately for those who want to follow ]]
<Zakim> kevin, you wanted to ask if it cannot go into About?
Shawn: Shadi's idea seems the simplest.
<Andrew> [note to Eric - 'back' button not working for me in FF42 / Win8.2]
Kevin: I'm guessing this note is a requirement to provide? Is that a definite?
Shawn: Would have to confirm with WCAG-WG. There have been serious issues in the past with authorities trying to *require* certain Techniques so we need to make clear it is not a requirement for WCAG conformance.
Kevin: My idea would be to remove the clutter and provide as a pop-up from an info icon
Anna Belle: Are there going to be any usability tests? This would be a great candidate for that.
<shawn> no UT scheduled
Eric: Not planned
AnnaBelle: Maybe some of our usability gurus could take it on on their own.
Shadi: What about at the end of the section? And make it more clear what will happen. Currently, the entire sentence is linked.
Eric: Yes we can move it around if we need to, but that will not solve the jumping around part
<shawn> -1 for end of the list
Shadi: If this is the first link they find, they will be tempted to click it and may get disoriented. If it is at the end, I will have more context
<shawn> straw proposal: Add one sentence in the About. Unlink the whole sentence. Add a link at the end that goes to the other page (not the bottom).
Shawn: if at the bottom it may get lost. If it is the first time they have looked at this, it will be important for them to see it. After that easy to mask out.
<Andrew> it is a 'note' - moving to the end of the section below the techniques it might get overlooked
Shadi: Not sure it needs to be so prominent but don't want to rehash.
Shawn: straw proposal: Add one sentence in the About. Unlink the whole sentence. Add a link at the end that goes to the other page (not the bottom).
<Andrew> [really does need usability testing for evidence either way]
Shadi: Add Kevin suggested an icon - what other page?
Shawn: The existing page, Understanding and could move the summary to the beginning of that page.
<shawn> -1 to icon
Brent: Any other discussion?
<shadi> +1 to suggestion
Brent: can we vote on the straw proposal?
Kevin: where specifically will the link be?
<Andrew> link to www.w3.org/TR/2014/NOTE-UNDERSTANDING-WCAG20-20140916/understanding-techniques.html#ut-understanding-techniques-othertechs-head ??
Brent: At the end of the sentence.
<shadi> [[Note: Other techniques may also be sufficient if they meet the success criterion. LINK See note on techniques /LINK ]]
Kevin: What will that link be or say?
<shawn> "see Understanding Techniques for WCAG Success Criteria." -> http://www.w3.org/TR/2014/NOTE-UNDERSTANDING-WCAG20-20140916/understanding-techniques.html#understanding-techniques
<shadi> [[Note: Other techniques may also be sufficient if they meet the success criterion. LINK See more on techniques /LINK ]]
<shadi> [[Note: Other techniques may also be sufficient if they meet the success criterion. LINK See understanding techniques /LINK ]]
Shawn: or See Understanding Techniques
Brent: Any other clarifications?
<shawn> [[Note: Other techniques may also be sufficient if they meet the success criterion. See _Understanding techniques_. ]] link goes to http://www.w3.org/TR/2014/NOTE-UNDERSTANDING-WCAG20-20140916/understanding-techniques.html#understanding-techniques
<shawn> [[Note: Other techniques may also be sufficient if they meet the success criterion. See _Understanding Techniques_. ]] link goes to http://www.w3.org/TR/2014/NOTE-UNDERSTANDING-WCAG20-20140916/understanding-techniques.html#understanding-techniques
<yatil> +1
Shadi: I like this suggestion because other places we have Understanding Success Criterias, etc. Recognizable and manages expectation for what this link does
Howard: To make sure I understand, the linked sentence will not change places, will just become unlinked? Will add note and that link will go to another page?
Brent: Yes
Eric: I support this as a proposal, do we need the other sentence and will it be similar to this one?
<shawn> For more important information about techniques, see Understanding Techniques for WCAG Success Criteria.
Shawn: It is vital, and it adds just one sentence, so I would favor that.
<shawn> For important information about techniques, see Understanding Techniques for WCAG Success Criteria.
<Andrew> [[For important information about techniques, see Understanding Techniques for WCAG Success Criteria.]]
<shawn> +1 !
+1
<yatil> +1
<Andrew> +1
<shadi> +1 to suggestion
<AnnaBelle> +1
<Brent> +1
<Howard> +1
<James> +1
<kevin> +1 but only as the best solution to a difficultly presented item
RESOLUTION: Add one sentence in the About. Unlink the whole sentence. Add a link at the end that goes to the Understanding Techniques page.
Eric: Currently it reads "Understanding SC 1.1, etc" One of the reviewers thought the hierarchy of WCAG remain somewhat visible, so the SC abbreviation was used. But have heard from a number of people that they would like it removed.
<shawn> +1 for not having "SC" or Success Criteria
Brent: It would not say SC or Success Criteria - it would leave only the number
<AnnaBelle> +1
<shawn> +1
+1
<yatil> +1
<shadi> +1
<Brent> +1
<Howard> +1
<James> +1
<kevin> +1
<Andrew> +1
RESOLUTION: Remove prefix SC from the listing of numbered success criteria
Eric: The question is whether to keep the icons since we do not open new windows by default, people can use their own controls to do so if they want.
Brent: Issue 44 mentioned that the icons are ambiguous people understand them differently
... discussion?
<Zakim> shawn, you wanted to comment on http://www.w3.org/WAI/sitemap icons
Andrew: There are similar icons in the sitemap and maybe other places
Shawn: We have tried to indicate what our icons mean on the WAI site map.
<Zakim> kevin, you wanted to say if we have to explain the icons, then they probably aren't doing what they should do
Kevin: Icons are meant to be intuitive, if it must be explained it is not doing its job. In this case, I don't think they are doing anything.
Sharron: and removes visual clutter
<kevin> +1 to removal of visual clutter
<Zakim> yatil, you wanted to ask shawn if external links opened in a new tab/window
Eric: Just wanted to ask Shawn if the tabs she pointed to - do they open new tabs or window?
Shawn: No
<shawn> +1 to not having icon after every technique
<yatil> <svg role="img" title="External link" class="i-external"><use xlink:href="/wai-wcag-quickref/img/icons.svg#i-external"></use></svg>
Howard: is there alt text that explains the icon? The icon seem unobtrusive and if alt text is clear it should not be a problem.
<AnnaBelle> I think this is another usability issue; my bet is most people would prefer no icon; certainly I would cuz of less clutter & visual noise
Eric: the title is "external link"
... it is SVG, the title would be the accessible name and read to screen readers.
<Andrew> +1 to AB
Howard: I see no harm or visual intrusion
Andrew: A bit of clutter but most who use this will understand the link to the appropriate page. I would be in favor of removing them from Understanding and from each technique
AnnaBelle: I agree but think it is a usability question. My guess is that most people would be fine without the icon and my preference is to remove visual noise. An obvious way to streamline to remove these.
Brent: I agree with Kevin - if we have trouble understanding what it does, we should remove it.
<shadi> +1 to kevin and brent ... i also think this particular icon is confusing
<Zakim> yatil, you wanted to propose a resolution
<shawn> + 1 to proposal to remove the icon
<Andrew> +1
Eric: No one feels strongly to keep the icon. In contrast there are those who do strongly feel it should be removed, so I propose to remove them.
<James> +1
<Howard> +1
Brent: Anyone opposed to removal of the icons?
<yatil> +1 to my proposal ;-)
<kevin> +1
<AnnaBelle> +1
<Howard> +1 for the good of the republic
RESOLUTION: Remove link icons from the Understanding button and the sufficient techniques section.
Eric: The issue was the background of the selected text, so I added a round mark at the top which marks it as selected.
... hope that makes it clearer and more understandable in proactice. Any opinions?
<shawn> +1 to tweaked design
Brent: everyone understand the issue?
<Howard> +1 like round dot
Brent: any comments or questions?
... any opposition?
Shawn: May want to consider the tick or checkmark?
Kevin: Yes the dot made me hesitate a bit - what is it for?
<shawn> translation "tick" = "checkmark" for some ;-)
<Zakim> yatil, you wanted to iterate on the tick
<yatil> HECK-shen
Eric: I had experimented with a Hakchen but it made the buttons larger and disrupted the visual presentation.
Shawn: a small tick/checkmark/hakchen even if subtle would be good
<shadi> +1
<shawn> +1 to small checkmark
<Brent> +1 to checkmark
<Andrew> +1 to try a checkmark
<AnnaBelle> +1
Eric: With no opposition, we can go to resoultion
<yatil> +1 to Hakchen
<Howard> +1 to try it but I think you'll find the dot might work better
<kevin> +1 to try tick
<James> +1 to a small checkmark, to me it doesn't matter if it's super clear it's just to show the difference without color.../p>
RESOLUTION: Replace dot indicator with small tick/checkmark/hakchen
Eric: There will be more questions in the survey for some of the issues where you can take a look and quickly comment.
<kevin> Alternative text tip in Designing
Shawn: Background is that in Tips for Designing we had one about alt text. Public comment was to edit to focus more on the design issues. Edits turned it into a different tip. Current thinking is to change the whole tip to address design for image alternatives and media alternative.
<kevin> Discussion on public comment and changing tip
Shawn: first question is do we want to make that change?
<AnnaBelle> I like it!
<Andrew> +1 to change
Ensure the design can accommodate alternatives to non-text content
<shawn> Existing title: Provide alternative text for images
<shawn> proposed new focus:
<shawn> New title: Design for image and media alternatives
<shawn> New content: Ensure that your design provides alternatives for images and media as needed. For example, you might need visible links to transcripts of audio or links to audio described versions of video, text with icons or buttons, or captions and descriptions for tables or complex graphs. Work with content authors and developers to provide alternatives for non-text content.
Howard: I am not against it, but I noticed that it is the most vague. it is pretty non-specific in its recommendation.
Brent: Do you have a suggestion to make it more specific?
Howard: Provide alternatives for images and media
... It is much more directive in what to do.
<shawn> [ writing task writes the alt text; developing task provides it in code. designing make a place for it in their design ]
Shadi: It is not providing the text for an image, it is much more about things that need to be visible such as a link to the transcript. Making sure there is space to provide alternatives if needed.
<shawn> [ me also wondered if negative connotations with "accomodate" ]
Sharron: design to accomodate alternative for iamges and media
Kevin: I get the difficulty with these - the tension of succinct balanced against specificity
<shadi> [[ include alternatives for images and media ]] -- or too subtle?
Kevin: design to include alternative for imagesand media
<kevin> [ Design to include alternatives for images and media ]
<shawn> Include image and media alternatives in your design
<Howard> agree with James
<shadi> +1 to shawn
James: Parallel construction is important - the simplest thing to say is provide. If the design does not include space for it, it is not provided. Are we being too specific about what provide means?
Sharron: public comment related to provide were negative - thought it was not clear enough about design aspect.
Brent: Most recent proposal is "Include image and media alternatives in your design"
<shadi> [[ can see james' point -- don't feel strongly either way ]]
Kevin: I have a mild/moderate concern that alternatives is still somewhat vague, not really specific enough, could be persuaded.
Shawn: But it is further explained in the Tip text, inlcudes example
Brent: and that is what the purpose of the text is - to provide a clearer picture of what this is about.
... does that satisfy your concern, Kevin?
<kevin> Yes, comfortable with that explanation
<shawn> Include image and media alternatives in your design
Brent: Can we accept this as the Tip?
+1
<Andrew> +1
<AnnaBelle> +1
<Brent> +1
<shadi> +1
<James> +1
<yatil> +1
<kevin> +1
<shawn> +1 for now -- and think we should "sleep on it"
<Howard> +1
RESOLUTION: Change Design tip title to "Include image and media alternatives in your design"
Brent: we will do a survey question on this next considerationand Kevin will introduce it now.
Kevin: The tip text as a whole as well as the question of what kind of example to add with the change in focus. The current one is not doing the work it should do.
Shawn: Issue is in the images tutorial we have led with the longdesc as the first example. Because of its lack of wide support it has been suggested to move that to last example. More information from PF says that longdesc is on its way out, will be deprecated as of first half 2016.
... Suggestion is to accept moving longdesc from first to last example of solution to complex images
Sharron: Proposed resolution is to move longdesc from first approach for solution to complex images to fourth approach.
<Howard> +1
<James> +1
<shawn> +1
<Andrew> +1
<shadi> +1
<yatil> +1
<Brent> +1
<kevin> +1
RESOLUTION: Move longdesc from first approach for solution to complex images to fourth approach.
Shawn: The second part of this is the addition of an icon, the word Warning and the change of "available to all users," to "available to mouse users."
<shawn> I looked around a lot and couldn't find if it was available to keyboard users. I found some bug reports about it.
<Zakim> shawn, you wanted to suggest just take out "all" !
<yatil> +1
Eric: I think there is a way for keyboard users to use context menus and screen reader users would also have access. no need to qualify.
Shawn: yes, we can just say "users" with no qualifier at all.
Brent: OK with all?
+1
<shadi> +1
<shawn> proposal: "...are available to users through ..." with no qualifier
<Andrew> +1
<shawn> +1
<kevin> -1
<Howard> +1
<shawn> revised proposal: "...are available through ..." with no qualifier
<shawn> revised proposal: "...are available through ..." with no qualifier (-users)
Kevin: mention context menu so it is clear that access is dependent on being able to get the context menu'
<shawn> +1 to revised proposal
<kevin> +1
+1
<Howard> +1
<yatil> +1 to revised proposal, thanks for clarifying, Kevin.
<shawn> In Firefox, long descriptions linked by longdesc are available through "View description" in the image's context menu.
<shadi> +1
<Andrew> +1
<James> +1
<Brent> +1
<shawn> +1
+1
<Howard> +1
RESOLUTION: Edit text to read "In Firefox, long descriptions linked by longdesc are available through "View Description" in the image's context menu.
Sharron: I think Warning is too strong of discouragement. makes it sound like 'use this at your peril.'
Sharron: The note itself says make these considerations before choosing this approach
<shawn> "Note" is not really needed - it has a nice heading already :-)
<Andrew> +1 in favour of dropping 'warning' as it is a note already
Shawn: I agree
<shawn> +1 for not adding icon and "Warning!"
<shadi> +1
<Brent> +1
<yatil> +1
<AnnaBelle> +1
<Andrew> +1 for not adding icon and "Warning!"
<James> +1
<kevin> +1 to not having icon and Warning!
Brent: Any objections to not accepting that warning message?
RESOLUTION: Do not accept the edit to add a Warning and warning language.
Brent: Open issues to discuss today and will follow up with survey questions and more discussion next time.
<shadi> w3c.github.io/wcag-em-report-tool/dist/
Wilco: There is the question of renaming the tool which I am all in favor of. People seem to think this is an automated tool. A possibility is to add assistant or generator.
Sharron: Generator wouldprobably add to perception of automation.
Shadi: Both Assistant and Generator imply more automation than what is actually resent. So what is the issue with the current name?
<shawn> [ me brainstorms: Report Formatter ]
<shawn> [ me brainstorms: Report Manager ]
Wilco: In testing it, people did not understand that it is a form that takes them through the process but will not run tests on its own. That is the perception we want to clarify.
<yatil> [ brainstorm: Report Helper]
Shadi: Report Tool implies for some people that it does more than it actually does, we want a word that communicates the manual aspect of it?
<shadi> [[ Report Creator ]]
<shadi> [[ Report Editor ]]
<shadi> [[ Report Builder ]]
Wilcon: Report Editor is a possibility
<shadi> [[ Report Template ]]
<yatil> [brainstorm: Report Manager ]
<shadi> [[ Report Boilerplate ]]
<shadi> [[ Report Maker ]]
<shadi> [[ Reporter ]]
<shawn> Report Template
James: Like builder and template
<shadi> [[ Manual Reports ]]
<shawn> Like the idea of builder
<shadi> [[ Report Toolkit ]]
Brent: Do we thing we have time to vote today or should we go to survey?
Shawn: Several people liked builder and template, can we pursue that if some people can stay?
<shadi> [[ Report Wizard ]] (from Eric earlier)
<shawn> WCAG-EM Wizard
<kevin> [[ Audit Assistant ]]
Wilco: It is more that it is about taking people though the process of auditing rather than creating the report...it is a process assistant. The process aspect is worth looking into.
<Brent> [[WCAG-EM Audit Assistant]]
<shawn> WCAG-EM Process Wizard
<yatil> [ WCAG-EM Audit Report Creator ]
<Wilco> +1 audit assistant
<yatil> [ WCAG-EM-ARC]
<shawn> +1 to Wilco on process not just report
<shadi> [ WCAG-EM Audit Report Builder ]
Sharron: WCAG Evaluation Process Wizard
<yatil> [ WCAG-EM Evaluation Process Assistant]
<kevin> [ WCAG Evaluation Assistant ]
<shawn> WCAG Evaluation Methodology Tool
<shawn> WCAG Evaluation Methodology Wizaard
<James> WCAG Testing And Reporting Template
<James> Would EM either scare people or make them think it's the only way one can evaluated wcag?
<Wilco> +1
<yatil> [ WCAG Evaluation Process Helper ]
Shawn: Pull it out of EM and say WCAG Evaluation Methodology
<shadi> WCAG Evaluation Methodology Assistant
<shadi> WCAG Evaluation Methodology Helper
<shadi> WCAG Evaluation Methodology Report Builder
<shawn> WCAG Evaluation Methodology Report Tool
<Brent> +1 for assistant
Eric: Methodology is not what you do with the tool, it is the process that you follow. Drop the word "Mwthodology" from the title is my suggestion.
<shawn> WCAG-EM Process Tool: [subheading]
<shawn> WCAG-EM Process and Report Tool: [subheading]
<yatil> [ WCAG Evaluation Process & Report Tool]
Wilcon: I am in favor, it opens to a broader audience, makes sense and methodology is a tricky word. it can still be based on this without being in the title.
<shadi> Evaluation Report Builder
James: Yes EM Makes sense to us but it may make them think this is the only way to do this. Keeping it more simple and emphasizing what it does without jargon.
<shawn> Web Accessibility Evaluation Process and Report Tool ... /me thinks it would be good to look over the previous discussions, especially for acronyms
<shadi> [[ /me doesn't like the "process" focus ]]
<Wilco> WCAG Evaluation Assistant
<kevin> +1
<yatil> [ Create a Web Accessibility Evaluation Report ]
Brent: We left off with the tendency to leave Methodology out of the name altogether.
<Wilco> WCAG Test Wizard
Sharron: WCAG Evaluation Template
<shadi> Website Accessibility Evaluation Assistant
<yatil> [ WCAG Evaluation Step-by-Step ]
<shadi> Website Accessibility Evaluation Guide
<Brent> +1 to template (forms to be filled out)
<shadi> Step-by-Step Website Accessibility Evaluation
<yatil> [ Interactive WCAG Evaluation Report Template ]
<shadi> Website Accessibility Template Builder
Shawn: Would people think it is a simple thing if it says report template, but leaving "report" out might do this.
<James> Since reporting is part of evaluating I support Sharron's WCAG Evaluation Template
Wilco: "Template" is quite different in the development world.
<shawn> template does not quite work for me
<yatil> Agrees with Shawn and Wilco.
Wilco: for people with background in development it would be off-putting
<kevin> As a dev, accepts there are two different applications to 'template'
Sharron: From Shadi's, a revision...Step-By-Step WCAG Evaluation
<yatil> Good point, shadi.
<James> I don't like step by step, says tutorial to me
<yatil> [ Step-By-Step Website Accessibility Evaluation Report Creation Machine ]
Brent: Thanks everyone for the brainstroming, will review and get some questions on the survey so please keep thinking about this.
Brent: Looking at W4TW, we get email out with updated survey questions, any last issues on the QuickRef, Kevin and james are working on updates to QuickStart Tips. Next week I will expand on this idea but want to set expectations for EO participants to do more of the actual editing and resource development going forward.
Brent: will be trying to get agenda updated as early as possible on Thursdays and ask you to look at the agenda, get familiar with issues so we have more background when coming to the meeting. Thanks for that.