See also: IRC log
<yatil> trackbot, start meeting
<trackbot> Meeting: Education and Outreach Working Group Teleconference
<trackbot> Date: 04 December 2015
<scribe> Scribe: Sharron
Brent: if you look a 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
informaiton to be simple and most useful, plese do make those
suggestions.
... questions or comments?
Kevin: Thanks for your reviews, comments and pull requests on Initiate section. If you ahve 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 secons 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 ManagingWeb 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 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
<Zakim> Andrew, you wanted to say planning is looking ahead rather doing the work
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 to 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
<Zakim> James, you wanted to ask about the Nav heading on the page that says "Managing"
Andrew: Planning and Managing is a better description of what we are supporting people to do. Strong support for both words.
<Zakim> shawn, you wanted to say SEO and people see it and think it applies to them
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 manging would lead me to think this is a resource
for PMs.
... I am back to the first simple, 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 accessiiblity 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
+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" essential
<shawn> +1 for including it
Kevin: question 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.
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?
<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
+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.
<Zakim> yatil, you wanted to argue that we should not broaden too much… and to say 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
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
<Zakim> yatil, you wanted to say WCAG glossary and to say or rather the use of a glossary in standards… and to ask about link to WCAG directly
AnnaBelle: If we are trying to make it visually quick as well, I am now rethinking my posiiton. 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
<shawn> +1 to shadi -- there isn't any more info in /TR/WCAG
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?
<Brent> Changing opinion... +1 to Shadi and Shawn
Eric: But if someone says I don't understand this, they could link on the Understanding link where the glossed words are linked.
<davidberman> I am happy with it.
Shawn: So I suggest that is 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
+1
<yatil> +1
<shawn> +1
<James> +1
<yatil> https://github.com/w3c/wai-wcag-quickref/issues/72
<davidberman> +1
Eric: Cannot use the reference "panel to the right." I was aware of it but culd 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
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.
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.
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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/of/or/ Succeeded: s/Mnaging /Managing/ Succeeded: s/Accessiiblity/Accessibility/ Succeeded: s/asection/a section/ Succeeded: s/compneent/component/ Succeeded: s/ahve /have/ Succeeded: s/ahve /have/ Succeeded: s/itslef/itself/ Succeeded: s/alterntive /alternative/ Succeeded: s/inlcuded /included/ Succeeded: s/tehir/their/ Succeeded: s/OKthanks/Ok, thanks/ Succeeded: s/finsih /finish/ Succeeded: s|http://0.0.0.0:4099/wai-wcag-quickref/|| Succeeded: s/plnning /planning/ Succeeded: s/ tot eh / to the / Succeeded: s/techniaues/techniques/ Found Scribe: Sharron Inferring ScribeNick: Sharron Default Present: David, Sharron, Brent, kevin, Andrew, EricE, AnnaBelle, shadi, George, Shawn, James, howard WARNING: Replacing previous Present list. (Old list: David, kevin, EricE, SusanHewitt, Andrew, Brent, Sharron, James, Shadi_on_IRC) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ David, Sharron, Brent Present: David Sharron Brent kevin Andrew EricE AnnaBelle shadi George Shawn James howard Regrets: Vicki Sylvie Susan Found Date: 04 Dec 2015 Guessing minutes URL: http://www.w3.org/2015/12/04-eo-minutes.html People with action items:[End of scribe.perl diagnostic output]