<Shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2010AprJun/0000.html
Shawn: We'll get started by working from the agenda.
Sharron: I looked through both versions and I am assuming we will ttalk today about which we prefer?
Shawn: Yes. Let's look at that "Basics" section.
Sharron: I preferred the bulleted aspect of the alternative version. That seems a good way to quickly communicate the issues.
Shawn: What about the second bit, how it is broken out? Notice that in the first version it is an explanatory paragraph, and the second one there were defined terms.
Sharron: I prefer the paragraph. The terms were useful, but oddly placed and not really explanatory enough all by by themselves.
Shawn: what do you mean?
Sharron: The terms that are presented here, seem to be only to do with hearing. Because they are so specific, it would seem more logical to put them in context. So I guess I am saying that we should add more terms to make the section apply more generally, or not have the terms definition at all, but put the specific definitions in context when they are encountered within the document.
Shawn: A screen reader might fit there.
Shadi: Can it, as William would
say.
... I feel similarly about the terms. It strikes me a bit odd to be right there up
front, instead of the bottom of the page. Why does it need to
be upfront? Is it so critical that we couldn't use the
document unless those tems were defined? Put at the end of the document. On the other point, I actually don't like the bulleted list very much. It is quite repetitive. There are also repetitive elements in the paragraph version but those could be easily fixed editorially.
As for the opening sentence in that section,
... my initial comment was about hearing impairments. I would
prefer that the terms would highlight the paragraph above. Make sure
to use the micorphone for those who use induction
devices, etc
... the examples should highlight the entire document. The
gist of the whole approach. Perhaps we select different types of examples for different kinds of disability, but CART doesn't belong up there in the very front.
Sharron: I agree. That may encourage people to think that those are the only issues.
Shawn: I'll move that to the end, and maybe add screen readers or additional references. I'm not sure we need to expand the examples. Adding more examples at the top feels redundent.
Sharron: I strongly like the basics crisply bulleted. Asking speakers to be aware that some people in the audience may not see, hear, understand in the way you do. The audience may have different capabilities. Encouraging speakers to change their expectations. So, I really like the basics presented as a nice crisp list that says here is the issues and inviting sepakers to keep these principles in mind as they read through.
Shawn: What if we did an editorial on the lines of deal with your audience - see hear, speak.
Sharron: Yes, that is OK with me as well, but this mode of presentation is an invitation to be voiced. I think it is just fine as is, it is almost a mantra, can't hear, see, speak as well. It seems very useful to get people in the groove and to have people understand.
Shawn: The repetitiveness works for me too.
Shadi: I see the point now. I agree to the bulleting and bolding. I think the suggestion to change to specific examples is useful. Let's say I am coming to this section and I am not familiar with these issues. So I learn to consider that audience members can't hear. what do I need to do? The first thing is to change expectations. We should be providing specific information to help meet those needs - make sure to speak clearly into the microphone and so forth. So I think we want to provide both the problem, what you need to be aware of, and also what you need to do.
Shawn: Take off the weller, and hear you talk?
Shadi: Sharron had a nicer way to say it. Sharron?
Sharron: You could expand the mantra to be specific to a presentation scenario, I suppose...see your presentation materials, hear your audio content, move to exercises, speak in response to questions.
Shawn: If we remove that from the list format, it might work. And if we do that - put see your slides, hear your voice in audio - it would only require a couple of things as examples. In that case, will people focus on only what is there, and miss other things? Maybe not hink of or ignore additional things that might be of concern but that are not listed as examples? Move to do activities, fro example.
Shadi: There are two answers to that. If we get all the presenters to understand those four bullet points, it will move them ahead a long way. It's better to remember these four things than to do nothing. And, it could be framed as high level. Analogous to the WCAG POUR Principles, perceivable,etc. ...So if it is framed as the highest level basic consideration, with the next logical level that if you want to make your presentation really accessible, read further into this document.
Shawn: ok. How about wrapping this up? Let's quickly play with this idea. Help think about what the words would be for each of these?
... what would we say for each of those?
... we are looking at the bulleted version or alternate
version, to do something a little different with the
bullets.
... basically be aware that some of your audience might not be able
to do things in a conventional way. We are missing the weller at all, if we just have the example.
Sharron: you are right that if we focus too strongly on the examples, we risk missing it. If you just use "well" there, you may miss the part about "see accurately or at all, hear accurately or at all". Are we trying to break up the repetition?
Shawn: what we are looking at is the alternate version with bullets. We moved the definition of terms down to the bottom. "see your presentation material, see / hear the audio."
Shadi: If I could add something after the well, see well or at all, comma, small text on your slides. Comments not spoken into the microphone. Move well, along for activities. As examples after that. What can I do with that right there?
Shawn: That's what this whole page is about!
Shadi: I don't see that link well here.
Shawn: One more sentence that said, this page helps you make presentations?
Shadi: The extra examples would ground the reader in the idea that people may not be able to see well. When I am making slides, I need to be careful, not only some of the audience may have certain kinds of disabilities, but what I might need to do within the presentation. I think we should be linking that stuff.
Shawn: see well or at all, describe your visuals or slides.
Sharron: The power of the current intro is the crisp focus. If we give too much, we need to go back to the paragraph. Further along we provide suggestions for specific thaings that a speaker should do. I don't think we want to be proscribing right out of the chute.
Doyle: I agree.
Shawn: I do too. I can kind of see Shadi's point. A short list is better. But with perhaps one more sentence after that.
Shadi: I am willing to let it go. The question is, I have one minute in an elevator, what would I say?
Shawn: Let's see if we can come up with one sentence.
Shadi: what are the next steps of this document? Some kind of EO review or approval, take the next pass. For editors discretion, and see with what you can do with this input.
Shawn: I think it has gone
through EO approval.
... it has, this is the only open issue. Then it is ready for
this one last bit.
... Not sure there would be any stopping comments.
... with the other document, Shadi do you need some more
feedback from this group?
Shadi: I don't think there needs to be more discussion, and we can make some changes.
Shawn: So some of the audience may not see hear, moce, understand... What would one more sentence be to make this work best?
Shadi: I thought it was in the bullets, some people in the audience could not see, hear some or at all, or participate in the acctivities. Right in the bullets there to clarify more.
Shawn: we thought the bullets would be left as they were, and add just one more sentence as a kind of conclusion.
Shadi: What was the idea, that the users may use some technology?
Shawn: The only purpose was to define ALDs and CART. The only reason for that there.
Shadi: Drop the sentence! :-)
Shawn: I sold myself on the idea of it being there. Therefore you need to describe important points in the slides, make sure to speak into the microphone, make sure the facility is accessible, and other details below.
<LiamM> Don't speak too quickly
Shawn: what about that?
Shadi: That is ok.
Shawn: Describe or say what is on your slides, put the text out,...
Sharron: Describe visual content.
Doyle: Use visual contents.
Shawn: Describe visual content,
speak into microphone, make sure the facility is wheelchair accessible, and see other
points below.
... How does that work?
Shadi: Great! That works really well.
Shawn: I like that it leads into the rest of the document. All happy?
Doyle: yes
Liam: yes
Shadi: works great.
Sharron: yes
Shawn: I will send out for comments. Thanks for coming up with the solution we are all satisfied with.
Shadi: Link from each term, ALD
now appears in the document has no description linked to that
term?
... I tend to not to assume, you don't know where people know where
people start reading.
... In a list under planning, I might go through I might not
read the first ALD. I don't read sequentially.
Shawn: I will do both. Do the link to terms. The terms will be in the page content also. Anything else? I will put a note in the document.
Shadi: One more comment. Some of the descriptions go on, over the heading with the content of the paragraph. I am not sure if I like that. Makes it more difficult to take out of context.
Shawn: Lets look at preparing slides and materials, the first one says make text big enough to be read from the back of the room. What would you do with that? Don't have to do each one.
Shadi: Yeah not for each one. I get really distracted from uneven ...did we consider flashing somewhere, like a roving camera flash?
Shawn: That falls out of scope, it is not a common enough occurrence. We don't want to complicate the document with it.
Shadi: yes, I'm struggling. This can be daunting for first presenting. Someone walked out of a presentation I made because they needed a diabetes shot. I don't know what that means, but we should hightlight that there are many requirements.
Shawn: I would like to have a short non-scary document.
Shadi: I agree that if we get speakers to do even just these things, that we have gone a long way.
Shawn: If there is nothing else on this one, let's look at
Shawn: we put this out a couple of months ago as a draft and received some suggestions and comments. We are now looking at the revised version with changes highlighted. New content, created in response to comments is in brackets. Does EO have any questions on those, or additional comments?
Sharron: Just as long as we included Liam's question - are you evil, or just stupid?
Liam: Are you evil, or just a disturbance in the universal calm?
Shadi: I think most of the suggestions are pretty straightforward. Further down in the section "Getting a response," one opinion is that the subject will almost always blame the assistive technology. Like, you are using the screen magnifier so the site doesn't work. Some of the users of the documents may not have sufficient background to say it is not part of the JAWS, or turn on forms mode, so there may be a bit of tension here. Will we not alert them to the fact that developers might blame assistive technology?
Shawn: in the previous draft, we had
advice something like, ...and therefore you might get someone who knows
web accessibility to help....
... But that idea is not in this draft.
Shadi: The way it was worded in the previous draft was to get someone who has more experience, but I felt we needed to do more to get this addressed. Wording that was more instructive and encouraging.
Doyle: Developers need to use an independent source of AT issues.
Shawn: Write guidance. An average developer knows the screen reader fairly well. I don't know code, and I know when I come across inaccessible web sites. Here is the problem with the site, it is not accessible. Our web site validates to HTML, and CSS, and been tested in QA testing, so it must be some problem on your end.
Doyle: I want to see a reference to independent qualifications.
Liam: Realistically, that is quite tough. Have you pressed enter? no...
Shawn: If the problem is with the user. In a good case, ideally. What about a case where the organization is just blowing them off becasue they don't know accessibility? Someone freaks out about a screen reader. I don't know that there is a short way to cover all the possibilities.
Shadi: We came to the same
conclusions. Unfortunately, misunderstandings on the user end really is an issue. It is one of the other things to consider - that tension. Unless we describe the different
kinds of cases. The developers might easily blame it on the technology,
but there is a reverse problem as well. Consider
your approach in that section. If I am an unexperienced user,
and I am having an issue, I would want to get more advice to
assist me through the process. Involving a third party
... to assist me with expertise.
Doyle: How will people find that?
Shawn: we do say in the beginning in the intro, that the problem may lie in the AT.
Shadi: Maybe be resolved by settings, because we said overcome...
Shawn: But that is not specific enough. We do link
to better web browsing, and note that some accessible problems are
inexperience related, but we don't know if we need to say that.
I think it is fine to put in here. Going back to the getting a response,
add the "sometimes organization that..." addition with some word
smithing.
... other thoughts?
... What was the idea of putting something to the "Consider your
approach" section. One concern is how do you find someone. Other
thoughts?
<Shawn> ACTION: consider in "Consider Your Approach" section adding a bit about getting someone to help you? [recorded in http://www.w3.org/2010/04/09-eo-minutes.html#action01]
Doyle: Suggest to use the manual on how to use JAWS on that order?
Shawn: other comments? Editors discretion?
Sharron: editors discretion is good.
Shawn: anything else Shadi?
Shadi: This was the biggest point of discussion. One of the things that cropped up, we had agreed in the task force. We are thinking what is the problem what about doing a screen grab for follow up and keep records.
<Shawn> ACTION: to "What is the Problem?" add idea of screen grab [recorded in http://www.w3.org/2010/04/09-eo-minutes.html#action02]
Shawn: I'll put that in the change log. Anything else?
Shadi: It looks pretty much like it was.
Shawn: Let's start at the top, A
couple of additional sentences and a change. Comments on
those?
... I think that sentence we need to say why we are saying
that, not always a specific accessibility issue, or something
like that?
... any thoughts on that?
Shadi: that relates to when do I know an accessibility know is an issue on behalf of the web site developers.
Liam: you will never be able to get end users to be able to do that robustly.
Shadi: Basically a lot of people complain when there is no problem.
Liam: I'll second that.
Shadi: Sp should there be a bit of warning to a user? Drop it?
Liam: False reports are a problem.
Shawn: I don't know if that first
sentence is helpful. Might complicate it.
... what was the discussion around that. Did they say that is
important?
Shadi: we left in as a safety net, but there was a sentiment to drop it.
Shawn: Some votes to drop.
Doyle: Does this not encourage them to report?
Shawn: I think having it there is more likely to deter someone.
Sharron: I agree with Shawn. People think "oh it's probably just me."
Liam: It is not the users job to be expert.
<Shawn> ACTION: drop "{ Other problems may be general usability and design issues that make a site difficult to use by everyone. }" because it is likely to deter people from complaining [recorded in http://www.w3.org/2010/04/09-eo-minutes.html#action03]
Liam: We are trying to give users more
encouragement to make complaints.
... It is better to know that people creatively don't understand
what you are doing. It tends to be a background in
accessibility that makes us take it up. But for other sites, most of the
complaints like I can't fill in the form, or can I turn off the
images turn out to be false.
Shawn: Under consider your
approach there is one minor addition, and the website is
significantly changed.
... anything on the paragraph?
Shadi: the second sentence is the one that is primarily changed.
Shawn: the first sentence is
changed, and the second and third are new.
... Is everyone ok with the paragraph under encouraging accessible
web sites? Under that way down keep records for further follow
up.
Shadi: what do people see under
where is the problem section? Some addition there?
... a second URL where is the problem. Anything special about
the URL? Thank you for the feedback.
Shawn: what is that URL?
LIam: I am not seeing a plain
text URL?
... I see a plain text URL.
<Shawn> http://www.w3.org/WAI/EO/Drafts/responding/
Shawn: Do you see the extra URI
in green.
... before I read your email. I did notice the PHP.
Shadi: The reason is there because that is a secured server. I personally am not convinced that this adds anything. We can live with that, but it really doesn't add much value.
Shawn: we were down under. Everyone looking at a page, and you want to get a copy electronically.
Sharron: screen shot.
Doyle: screen grab
Liam: screen grab, and picture.
<Shawn> [terminology research: google results: 48,700,000 for screen shot; 21,500,000 for screen grab; 17,500,000 for screen capture; 1,210,000 for screen dump]
Shawn: change capture to grab. Any comments on the first bullet?
Shadi: I know screen shots, screen grabs, or captures I thought they are different, pick one.
<Shawn> ACTION: use just "screen shot" not or capture [recorded in http://www.w3.org/2010/04/09-eo-minutes.html#action04]
Shawn: I agree any objection to
screen shot?
... basically anyone who knows how to do it. Anything else? The
next change is getting a response we talked about, the next
change is further action to consider are fairly minor. Any
comments?
... the next change in sample email number one. Pretty
minor.
<Shawn> Any other comments you think we need to address differently http://www.w3.org/WAI/EO/changelogs/cl-responding.html#commentJan2010
Shadi: regarding sample emails for completeness sake. There was a proposal to have a sample email for positive feedback. We felt it was out of scope since this was about inaccessible web site. We covered some of the stuff by choosing your tone. Motivating like good feedback is good motivating, that email is more for the document for contacting organizations with accessible web sites.
Shawn: the final question I have. Any other comments? Have we adequately addressed these comments. From that link consider the section feedback in the public comment phase. Are we comfortable that we addressed as best?
Doyle: I'm good.
Sharron: I'm good
Liam: I'm good and this is good to go.
Shawn: anything else on this document? Gone. Just make sure you have the survey the agenda, so ...
Sharron: when is the face to face? Do we have a date? Any suggestions?
Shawn: no date yet.
Shadi: basically we are happy to host any date preferred so what we want to do before, or the after or on the weekend.
Sharron: when to book a flight?
Shawn: it would help to get some
dates, I'll work on that.
... anything else. have a wonderful week!