- Minutes -

Education and Outreach Working Group Teleconference

04 Dec 2015


EOWG convened to consider public and EO comments on the Planning Guide and QuickRef as well as ongoing EO business. Discussion of the suggested re-titles of the Planning Guide resulted in the following resolution.
The resource will be renamed Planning and Managing Web Accessibility.

Next was discussion of how to reference existing EO resources within the Planning and Managing Web Accessibility (PMWA) tool. The question concerned making an exception to the convention of referring to supporting EO documents within a "More information" section. For the 25% or so of activities that will have direct correlation to an activity (such as the Business Case) should the reference be made inline to the activity description instead? This question will be on next week's survey. Next was a consideration of a change suggested by a public comment on the Getting Started Tips. What was previously a focus on alt text for images has become a broader tip that includes media accessibility, putting the The Tip title and content out of alignment. Kevin will consider points made during discussion and bring a new version back next week. Eric then walked EO through the updates made to the QuickRef in response to public comment. Suggestions for response to selected public comments include:

Finally, the group considered the recent pull request that changed the order of the solutions for complex images (in the Images Tutorial) and issued a warning about browser support for longdesc. EO chairs will coordinate with WCAG to determine next steps. Brent reminded everyone of the need to stay current on Work for this Week, surveys, and completion of availability for teleconferences and F2F meeting in 2016. Thanks all!



David, Sharron, Brent, Kevin, Andrew, EricE, AnnaBelle, Shadi, George, Shawn, James, Howard
Vicki, Sylvie, Susan


Brent: If you look at the agenda, the Work for this Week is at the top. We have been playing with the order since we want people to understand what is on the survey by reading the listings before they go to the surveys. We have been trying the order a bit differently.
... we noticed now that people may have overlooked a survey becasue of its placement in the list. Think we will keep the survey links at the top. Any suggestions about how to list this information to be simple and most useful, please do make those suggestions.
... questions or comments?

Planning Resource

Kevin: Thanks for your reviews, comments and pull requests on Initiate section. If you have raised an issue, when I respond please feel free to close the issue if you are satisfied with the response.

<kevin> https://www.w3.org/2002/09/wbs/35532/EOWG120Nov2015/results#xq4

<shawn> [ Shawn would like to check in on Managing ]

<shawn> I have a feeling that "Managing" could be important for SEO.

<shawn> Is it appropriate to include "Managing" based on the content? (from survey)

Kevin: one of the survey questions was about a name. After a reasonable number of responses, we had a very close finish. I assigned numbers and subtracted for those that said "don't want." Based on the excercise, the highest score was for "Planning for Web Accessibility." But there was a close second and so we might want to discuss it. It is Web Accessibility Planning Guide. Discussion?

<davidberman> I am fine either way

Shawn: Based on the content of the resource, is Managing approriate to the title?

Andrew: Based on the Sustain section, Managing seems a relevant title

Kevin: If we went with Planning and Managing Web Accessibility, would anyone object?

David: I can live with it but seems wordy.

Sharron +1

<George> +1

AnnaBelle: I agree, I can live with it, but seems wordy.

Sharron: I did not rank it highest mostly because the managing seems like just one aspect and not enough to be added to the title.

Shadi: If it is a matter of length, we have a section called "Plan" and maybe the word to drop is Planning and just call it Managing.

<Andrew> +1 to shadi

Brent: Yes, if we analyze the resource, we find that it actually is more about Managing and planning is just one component of it.

<shadi> +1 to brent

Sharron: that makes sense to me

<Andrew> +1 to Brent too - planning is just the start point

Brent: I would leave it as it is - Planning and Managing

David: If it is just to be an advocate, it seems paternalistic and we should take Managing out.

Howard: I would agree with Brent to keep it as is. No reason to take any of them out. Planning is a nebulous word. In combination, it presents a model where you start, engage, and maintain it. Planning alone is too vague, the use of the two words gives you a better model of what this tool is all about. Two words is not too cumbersome.

<George> +1 for howard

Andrew: Planning and Managing is a better description of what we are supporting people to do. Strong support for both words.

James: Where will this document end up? Will that have an effect on the name?

<kevin> http://www.w3.org/WAI/managing.html

Kevin: It is intended for the Planning and Implementing as the first link within the Strategic Planning section

Shawn: We had noted that we may tweak the nav based on the placement of the resource, so it is not a defining issue. Managing is something that we want to be let people know there are resources for.

AnnaBelle: For me the title planning and managing would lead me to think this is a resource for PMs.
... I am back to the first simple title - Planning for Web Accessibility

Kevin: Planning and Managing was the first choice, Web Accessibility Planning Guide was the second.

AnnaBelle: Part of SEO is making people want to click, addition of the word Managing would make me less likely to click.

Shawn: But is this resource intended for your role as a developer?

AnnaBelle: maybe not my primary role, feel free to disregard.

George: I strongly agree with the addition of Managing, if I saw that word, I would be drawn to it and not have the association with PM. How to get accessibility through business processes seems like a good direction.

<AnnaBelle> George just convinced me too.

Shadi: The discussion convinced me. One key audience are those who are in roles of responsibilities and don't alway realize it. We think many of our audience may not be trained PMs but may have responsibility for some parts of it and need help. Having both words supports a wider set of roles.

Kevin: To summarize, either would work, still seems to be more of a leaning toward Planning and Managing. Are people comfortable with that?

Propose that we accept the title Planning and Managing Web Accessibility.

<shawn> +1

<Brent> +1

<shadi> +1


<yatil> +1

<AnnaBelle> +1

<davidberman> -1 (but will not block consensus)

<George> +1

<James> +1

<Andrew> +1

<kevin> +0 but happy with consensus

<davidberman> "Web" is essential

<Shawn> +1 for including it.

Kevin: Questions were raised about inclusion of 'web'

<davidberman> ... or something else that implies e-Accessibility

<Howard> +1

<George> +1

<Brent> +1 for "web"

<yatil> +/- 0 to web

<Howard> +1 for keeping web

<Andrew> happy to include, though it applies more broadly

<shadi> +1 to web

<shawn> WAI scope is web

RESOLUTION: The resource will be renamed Planning and Managing Web Accessibility.

<yatil> +1 to not broaden as long as we don't have things in there for other documents.

Planning - relation to existing resources

Kevin: Many of the references we make have relationships to existing resources. Should the activity point out to those or should guidance be placed inline of the activity itself. We will havea look at that during the survey next week, so keep that in mind.
... questions?

Brent: You have laid out the two examples and we will determine which is preferred. Do you havea sense of how many of those there might be?

Kevin: Not a clear idea since the resource is not fully developed as yet.

Brent: OK I just want people to be aware that if we propose the inline solution it may not be applicable to all of the activities.

Kevin: Yes, good point, and other questions?

<Zakim> shawn, you wanted to say (after others)

Shawn: I have a strong opinion. I think if most sections have a link to elsewhere "More information" and then some section do *not* have that, we risk that people will miss it. They will be expecting to find detail as a linked resource and may miss inline info.

Shadi: Would you be looking for one heading or what? Maybe you can expand your ideas in the survey?

Shawn: Yes maybe to explore placement so that inline info does not get lost. In those pages that have related "more information" that will give you exactly what you need vs something that is tngentially related.

Kevin: For some activities there are resoruces that are so closely aligned that is the only one we will point to. For others, there are resources that touch on some of the points, but not completely aligned.
... for example in Learn the Basics, there are a number of resources that are valuable, intros and HPWD Use the web. None by itself is sufficient to cover all of the Basics, but all are related. But then for the Business Case, there is only one resource that we have that addresses that.

Sharron: And the suggestion is to bring the info into the resource itself inline rather than link out?

<shadi> +1 to tweaking

Kevin: Oh no, just to put the link in the activity text rather than in a More information section

Brent: OK let's be sure the survey question is clear. Anyone else have last comment on that?

Getting Started Tips

<kevin> https://github.com/w3c/wai-quick-start/issues/297

Brent: We need to discuss a few other issues before the next release.
... comment from a public comment suggesting an alternativeto alt text in designing. I integrated his suggestion and it has been includedin the next propsed published version. Shawn has raised a concern that the Tip title no longer aligns to the content.
... how to respond? Change title of tip or review content of tip...or what?

Sharron: Why could the title of the Tip just be broadened?

<Brent> Shawn's comment: https://github.com/w3c/wai-quick-start/commit/61a6cae

Kevin: There was strong feeling among EO participants that alt text for designing was important as a necessary tip. Is it the images part that is most important and necessary?

Brent: Let's take a bit of time for discussion.
... what are the opinions?

Sharron: Tip title should be broadened in my opinion.

<davidberman> +1

<Andrew> +1 to broadening the title

<Howard> What about "Provide text alternatives for Images and Media"?

<James> +1


<Howard> +1 to broadening the title

<George> +1

<Brent> +1

<davidberman> "Prove text alternatives for non-text content"?

<Andrew> "Provide alternatives for Images and Media"?

Kevin: Shawn does that address your concerns?

Shawn: Yes that addresses the first concern but I had multiple concerns.

Howard: The reason I said text alternative is to avoid the connotation of the alt text.

<shawn> andrew's is broadest: "Provide alternatives for Images and Media"

<Zakim> shawn, you wanted to say in big picture then we tak about media here but not others...

David: I liked Howard's comment and if you start listing things like media, there are other things like controls, so maybe text alternatives for non-text content.

Shawn: let's take a step back. On designing and writing we do not have broad issues about alt text. Since we do not address media at all in any of the other sections.

Sharron: If that's true it is a big oversight.

Eric:Just wanted to argue that we should not broaden Tips too much...and to remind us to think about the nature of the tips

Kevin: Writing has reference to transcripts, development only alt text for images.

Eric: When we broaden tips in that way, perhaps we make them less clear. Instead perhaps split them in two, it may be confusing to people to get their head around all of these rather than having one very specific tip for images.

<shadi> +1 to eric ... KISS ... keep it short and simple

Sharron: Good point

<Zakim> shawn, you wanted to say like designing aspect

Shawn: One of the things that I did like about the spirit of the rewrite was the emphasis on the designing perspective. I would encourage us to think about how to make a Tip that is clear and focused on the design aspect.

Kevin: I will go back to the drawing board with this.

Shadi: I want to be sure we have addressed the controls with the idea of lables. We have tried not to be exhaustive but to give people very tightly prioritized and focused "tips" that will get them started.

Brent: Ok, thanks everyone, Kevin will work on that and bring back the changes when ready.


<yatil> https://github.com/w3c/wai-wcag-quickref/milestones/Public%20Review%20Comments

<yatil> https://github.com/w3c/wai-wcag-quickref/milestones/Public%20Review%20Comments

Eric: We got results from public review. We received many comments, many of them interesting and useful, some more nitpicky. We have reviewed all of them

<yatil> https://github.com/w3c/wai-wcag-quickref/milestones/Late%20Public%20Review%20Comments

Eric: Minor things like bugs that need no review. One of the main things to finishis to get the WCAG data brought into there, we got feedback on tagging, some browser bugs. One asked for a sentence of explanation for each SC we determined that was out of scope.

Shawn: That is something we have wanted to do for years so if we acknowledge that in response to the comment and be sure to keep it high on the wish list for future versions.

<yatil> https://w3c.github.io/wai-wcag-quickref/

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/76

Eric: Now workable in all browsers and it was suggested to add a note that "other techniques may be sufficient..." from previous versions of the QuickRef. This lets people know this is not the exhaustive lsit of techniques. Commenter wanted that note reintroduced.
... a concern that such a note on every item would add to clutter.

Shawn: There was a point at which some governments were planningto require certain techniques, which is not the intent. We went through a large outreach effort to inform them that none of the Techniques is a requirement.

Eric: We have considered adding a note to the About section rather than the specific techniaues. It will remove clutter but the individual notes would only be seen in the About section. Could add before the All techniques button. Then it would be spread around throughout the doc.

<Brent> http://www.w3.org/WAI/WCAG20/quickref/

<yatil> "Note: The basis for determining conformance to WCAG 2.0 is the success criteria, not the techniques. (The success criteria have 3-level numbering (0.0.0) and in this page they are followed by a link "Understanding Success Criterion".) All techniques are informative; that means they are not required. There may be other techniques besides the ones listed here."

Brent: In the current How To Meet, there is a tope section of the document before you get to the ToC, with a comment that other techniques may be sufficient.

Eric: Yes and when you scroll down there is an additional note that says there may be other techniques..

Brent: Thanks for the clarification

Eric: So we need to think about two things: Do we want the note in each technue box, and where do we want general info?

Shawn: A minor data point, I did not even notice that note . The masking effect may meanthat the clutter is not that bad.

Eric: Yes, it is not too bad, we may be able to do the repetition and be good with that.
... And do we want to link out to more information?

Shawn: Yes, either link up or link out.
... which draws more attention.

Eric: OK I will put the info in each box and link up or out and bring back to the group. Back next week.

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/82

QuickRef link to Glossary

Eric: We deliberately left out the link to glossary items

<yatil> http://www.w3.org/TR/WCAG20/

Eric: if you look at WCAG itself there are many interlinks to glossary terms.
... also in the current How To Meet as well.
... at some point we determined this would mean unneeded clutter for the intended audience. I wanted to bring this up to collect comments. Do we want to provide some type of glossary or link to it from the About section, or address this comment in some way?

AnnaBelle: I think it would be nice if we could do it, but not sure it si worth the effort. Is it a great deal of work Eric?

<shawn> mild +1 to providing links (but I could change my mind :-)

Eric: Not sure it depends on access to the data source so I am not sure how to estimate the work.

AnnaBelle: Maybe put in another version?

Sharron: I favor the link to the glossary in the About section

Brent: I completely understand that point of view, adds a lot of clutter and visual noise and how I felt about the WCAG materials at first. With my content team, however, as I was taking them through itit was great to have the direct link.
... not necessarily needed in the How To Meet but from the WCAG itself.

<Zakim> shawn, you wanted to mention glossary links milder visually

Shawn: In the current HowToMeet the glossed words are much milder visually, the text stays black and has a dotted underline. Keep that in mind as we think aobut this.

Eric: Yes we could certainly do something like that here.

Brent: I am interested in the screen reader behavior.

AnnaBelle: Sharron's point about the visula distraction vs Shawn's that it is minimized. It is the extreme tension between trying to create a "QuickRef" and still be informative.

<shawn> +1 to the idea of "tension" / balance between "quickref" verses .... ALTHOUGH we are promoting this as *the* primary resource for people to use

Eric: What about using the WCAG glossary or rather the use of a glossary in standards...and should it link to WCAG directly?

AnnaBelle: If we are trying to make it visually quick as well, I am now rethinking my position. As long as there is a glossed version available in the non-Quick presentation of standards.

Eric: And some terms may not need definition in a day-to-day usage. We do not have a direct link to the actual WCAG document here, but could introduce a link to the spec.

AnnaBelle: I thought I was going from QuickRef to WCAG, is that not right?

<Brent> +1 to linking SC #s to WCAG

Eric: We link to the Understanding document

<shawn> -1 to link to SC in WCAG proper

<shawn> you get to the text from the understanding doc

<Brent> Ah, thank you Shawn.

<shawn> -lots to link each SC in WCAG proper

Shadi: Good to link to the actual spec somewhere in the tool but don't know when you would be reading the SC in the tool and say I want to go to the actual spec? Why would anyone do it?

<shawn> +1 to shadi -- there isn't any more info in /TR/WCAG

<Brent> Changing opinion... +1 to Shadi and Shawn

Eric: But if someone says I don't understand this, they could link to Understanding where the glossed words are linked.

<davidberman> I am happy with it.

Shawn: So I suggest that as our response: In trying to provide QuickRef we are avoiding visual complication. A link to the Understanding document has the full spec including links to glossary terms.

<AnnaBelle> +1

<Howard> +1

<Brent> +1

<shadi> +1


<yatil> +1

<shawn> +1

<James> +1

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/72

<davidberman> +1

Quick Ref - Filter Intro

Eric: Cannot use the reference "panel to the right." I was aware of it but could not think of better wording before public review. Can I get your quick reactions? Not a lot of wordsmithing but if someone has a good quick idea. Do we need the intro text at all.

<Brent> "Changes in this panel are reflected in the main content panel:"

Shawn: Changes to the filters will change the SC and techniques that are listed

Eric: I will put a question into the survey

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/77

QuickRef - visual polish

Eric: One comment was that visual presentaiton is cluttered and unrefined, especially in the main content area. I have moved buttons around, tried to polish the typography, iconography. Solved some problems with the tab order as well.
... hope it is much cleaner, is this the right direction to continue? Consolidation etc.

AnnaBelle: I like the visual presentation Eric given the complexity of the task. If you would like for me to talk with you offline about polish, I will be happy to.
... I have been thinking about some of these design issues so let's talk.

Eric: Yes sooner better than later. Any comments on the share link?

Brent: Thanks for this work Eric and your openness to feedback. Will be questions on this week's survey.

Intro to longdesc issue

Sharron: https://github.com/w3c/wai-tutorials/issues/330
... EO chose to give instruction about the use of longdesc as the first option for complex images because it is the solution that theoretically provides the greatest benefit to the largest group of users including those with low vision. Only theoretically however because it is not widely supported. Support details are in a sidebar. Mnay advocate for keeping this a s the first solution to

bring some pressure to bear on browser makers to support.

Brent: Any stong opinions as we bring this issue to the other groups?

<shawn> Sharron: his pull request changed other things as well, e.g., changed the sidebar to a warning (which is a discouraging message)

Brent: Stay in tune with the issues so that we can make an informed decision about it. Any other itmes for discussion?

David: I was in consultatin with Mexican government and asking for Spanish language versions of resources.

Shawn: Yes we do, send an email and I will point you to them.

Work for this week

Brent: Please be thinking and commenting on the survey about your availability on the F2F suggestions. Will be survey questions on Planning, QuickRef and more. That is it for me, anything else?

<davidberman> excellent meeting, all!

<davidberman> have a fine week.

Brent: thanks everyone, we are adjouned, will keep you posted on W4TW and ongoing work.

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. The resource will be renamed Planning and Managing Web Accessibility.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2015/12/04 15:32:51 $