Agenda in e-mail list archives: lists.w3.org/Archives/Public/w3c-wai-eo/2004AprJun/0121.html
No outreach updates.
SLH. Web accessibility intro. We spoke two weeks ago about intro pages. This is short intro for people new to subject, with links to related docs. Would no longer have current "getting started" page. This intro instead. Spoke about this in redesign task force. Want to clarify myths on site, but not in this document. But must not perpetuate myths in it either. Style considerations will be dealt with in site redesign. Now discuss requirements.
JB. Comments?
HS. Will we do intros for other docs or just this one?
SLH. This is about Web accessibility general. We discussed last week the Requirements for Introduction Pages for WAI Site, Planned Intro Pages - thinking of doing this one, one for WCAG, one for ATAG, and one for other accessibility features, etc.
JB, HS. This will be a template for the other documents.
SLH. Now look at document itself and review questions. Should it be shorter? Two versions? Are the correct resources referenced? Add, remove things?
DS. Blank spaces between sections for me. Column on right maybe causing this.
SLH. Design will be changed completely in final design. Am proposing three sections: Main text, example and further information.
RC (on IRC). I agree in changing the order.
AA (on IRC). Swap the order of making and evaluating?
HS. Maybe we should change the order. Swap the order of the "making" and "evaluating" sections.
HBj. Think it's correct as it is.
DS. Beginners do the evaluation first; agree with HS.
SLH. In ideal world, doing would comes first, evaluation second. In practice eval first.
HBj. Evaluation should be further up in list. Before benefits section.
SLH. Need to consider the audience. For example, scenario of manager of site, was given a link to this page, knows nothing about it.
CL. List of sections only five, people not likely to get lost. Fine as is.
SLH. Maybe we should leave discussion of order of sections until later?
HS. It's not necessary to spend a lot of time on it now.
SLH. No need to put that in changelog yet.
HS. Agree.
JB. What are people's general impressions.
HS. Evaluating section first para is two sentences.
HS. It's not easy to do.
BM. Like the content, but have trouble focussing.
DS. Me too.
JB. My reaction was that it's a great document.
RC. Anyone who doesn't know about web accessibility, may be put off when starting reading. Non-disabled reader may lose interest. Should emphasize benefits to all users, from the beginning.
JB. First reaction was how good to have everything in one place. One fairly reader-friendly page.
JB. Would like to get other people's reactions. And then get back to RC's comments.
HS. Yes, it does fill a gap. The getting started page is overwhelming with so many links, and this is a good summary.
RC (on IRC). I agree with HS.
HS. If we decide to only use two pages, we will have to wrestle with priorities.
BM. Agree with HS, still a gap.
HBj. Agree with HS and JB.
AA (on IRC). Agree it fills a gap too.
SLH. Back to RC's comment, that people could initially miss the point because it focuses on PWDs.
JB. Have trouble with the idea that we have to first mention non-disabled. Maybe need to rewrite first section but can't justify it saying that not only for PWDs.
HBj. Include term "universal accessibility for all users". Terms used in design for all community.
RC (on IRC). Good point.
SLH. Avoid using terms not known to newcomers. What's missing is the idea of everybody but being careful about strange terms.
RC (on IRC). But they can easily understand that the Web is universal, or it should be universal.
AC. Perhaps universal design is easier to understand than Web accessibility.
DS. That makes sense to me.
HBj. Last sentence, "different needs and preferences" is something like that.
SLH. Does everyone agree to keep focus on PWDs and also the wider scope?
HS. Although other user groups benefit, focus on disabled.
SLH. In why important section.
AC. That sentence could be baffling for newcomers.
AA. Examples break it up too much as is now. Lose flow of ideas. Maybe hide or show according to user preferences.
SLH. Could change position or hide and display, or put in other page. Tried that at TRACE but nobody has satisfactory way to do it.
HS. Think we should try to keep them in, but agree with AA that they break up flow.
HS. But sometimes an example can clarify things immediately.
DS. Would like the examples formatted the same as rest. Doesn't make sense to move them into other document.
CL. Discontinuity, first example is four times longer than section it explains.
BM. Really breaks the flow.
SLH. All agree to leave examples in but change formatting?
[silence of agreement]
SLH. What should be first example? What do you say to someone with no knowledge.
DS. Like the screen reader part. Explain what screen reader is. Importance of alternate text.
HS. Without describing how it's done.
BM. Is not an example of web accessibility. Maybe don't need example in separate flow. Could be just another paragraph.
SLH. Say you meet someone on airplane. ¿What do you tell them?
DS. How one AT might work.
BM. Let's keep it short and sweet.
RC. When I give a talk about web accessibility, turn of light, or screen, and ask people how they access the Web.
SLH. OK in a presentation - not sure about in written material. That works well in presentations. Need to balance.
RC. Challenge is to make the new reader understand that it's something that can happen any user.
SLH. That is beyond scope of this document.
RC (on IRC). OK.
[RC has to continue by IRC due to heavy echo on telephone line]
AA (on IRC). AC: rather than explain AT, try "consider that many people can't use a keyboard, but can use a computer - how do they do it?" or "some cant see the screen - how do they use a PC?".
AC. Maybe we can keep it short by just describing the disability and letting the reader work out how PWDs access web.
HBj. Think that HS's suggestion is easier to explain. Doesn't assume knowledge of HTML.
HS. Everyone could write their own ideas [and then we can compare them].
DS. HS's idea is simple.
SLH. Consider scenario of meeting web developer on plane.
AA. Example person may fall down stairs and break wrist. Easier to imagine that losing sight.
HBj. People get tennis elbow; common condition.
RC (on IRC). We may say: "Imagine your mouse doesn't work; how can you surf the web?".
DS. Or person loses mouse.
RC (on IRC). Right; yes.
SLH. Need to have a very short example. Replace image example with mouse one?
SLH. All agree?
[silence of agreement]
HBj. Link to online slide in example breaks the flow.
[AA takes over minuting]
SLH. Do we need examples? Maybe not with all sections - just some? Maybe just one example on the page - use mouse one.
BM. Incorporate example into the text. Then areas will flow on from each other.
RC (on IRC). What about starting every paragraph with a good, simple example?
SLH. looking at the remaining three sections - do we need examples? propose that no examples needed in last section.
[all seem to agree]
SLH. what are the three questions that the person on the airplane is going to ask - will this document answer them?
[silence]
JB. what about at a party?
SLH. a reporter?
SLH. any other comments for the next revision?
HBj. "accessibility also benefits people without ." - I feel that it stresses that "accessibility" web site are different from normal web sites.
HBj. no difference.
RC (on IRC). That's the main point.
SLH: OK. have in changelog. See change log at http://www.w3.org/WAI/EO/changelogs/intro.
HBj. i need something about the multi-modality aspects/benefits of accessibility.
RC (on IRC). Accessibility audience is the whole Web.
DS. ref to slow 'net connections is not needed.
HBj. what about mobile devices?
DS. build up a bigger picture about how is affects everybody.
RC (on IRC). From WCAG 2.0 working draft http://www.w3.org/WAI/GL/WCAG20/.
RC (on IRC). principles for creating accessible Web content. When these principles are ignored, individuals with disabilities may not be able to access the content at all, or they may be able to do so only with great difficulty. When these principles are employed, they also make Web content accessible to a variety of Web-enabled devices, such as phones, handheld devices, kiosks, network appliances. By making content accessible to a variety of devices, that content.
AA. like to keep slow connections eg in somewhere - affects a lot of the world, so many people relate to it.
RC (on IRC). Agree with Andrew; slow connection are still a real problem.
SLH - What the "more on" sections? Comments on the "more on" sections content - are they too wordy? do they have the right links?
HBj. Can we take the eg from the online slide about disabilities and put here?
SLH. Better covered in "how PWD use the web" which is linked.
HBj. Under social factors - can we find another eg instead of "older people" grouped with PWD.
SLH. Older people is primary motivation in some areas. What if we dissociate older from PWD.
BM. If groups who benefit are important - put into text, not in sidebar.
HS. Agree.
BM. "more" sections work when short - don't put egs in.
SLH. "legal" is missing from main text - policy/legal/etc. only in "more" section - should we move something into the main text? what and how much?
BM. fine where it is.
HBj. should that be one sentence under "why" - because of legal requirement.
SLH. what do people think?
HBj. many people say "I do accessibility because otherwise I'll get fined".
JB. agree this is important. should be trying to keep short as possible - even the number of links will slow down people's skimming.
SLH. can we cut down more? can we cut any ideas from the "why" section? eg do we need to say "millions of PWD use the web"?
HS. keep it - most don't appreciate the numbers of PWD.
DS. like the concept that there are barriers there that don't have to be.
HS. if we reduce too much, then danger that some people will not understand.
SLH. any other suggestions for next revision?
[silence]
SLH. "what" was commented on as being v.short - any ideas missing?
HS. have we mentioned the WCAG? Should add early into text.
SLH. good - what else?
SLH. OK - done for today? please send anything else to the list - I'll have another version for next week.
JB. Next agenda item - "Starter Lexicon For WAI documents" .
HS. Hope I've got all the comments from last week (no minutes at the time Irevised). change of title needs to be reflected in a few places in the body. also added a new section called "process" - maybe we should look at it now.
JB. any first reactions?
CL: Mary Francis liked it - comment made to Chuck who concurs.
SLH. change from "us English" to just "English"?
JB. Yes - agreed to focus mainly on difference between countries, but not so much on "non US English" as couldn't come up with examples that emphasised this as a problem.
HS. I hesitated on this without the minutes - I think you're right.
JB. part of my concern was "is it specific US terminology"? or is more about "people who are not familiar with certain regional terminology".
JB. hope that new WAI docs are not regionally biased in future. any general comments? did Sylvie comment on the title and internal consistency?
HS. yes - and i will take on board.
JB. what do people think about "Beginners Lexicon For WAI documents"?
JB: must be OK - no adverse reactions. contrast with "glossary" is now much clearer. In "scope" do we mean "beginners docs"? Thought we were referring to translation priorities.
HS. will change to "most read" docs and reflect the translation priority list.
JB. did Shawn talk to someone about getting site stats?
SLH. yes - we can get - Shadi was going to follow up.
HS. priority list should also be revised - raised at last meeting.
JB. may be interesting for a number of purposes to get stats.
JB. please look at "scope" section - any comments?
JB. does "top ten" most read docs make sense as the starting point for terms.
HBj. lets also look at what docs are most translated - if a large number of translation of a certain doc, then maybe it had no problems.
SLH. lets check our list, and then ask translators for terms they had problems with.
HBj. agree - but sounds like a huge task.
JB. could we revise scope to reflect a number of criteria - including "know problems with translating certain terms in frequently translated docs" etc.
JB any other comments on the scope question?
JB. silence = agreement?
YES.
RC (on IRC). yes.
JB. "process" section - comments?
[silence]
JB. "contents" and "examples" - any comments?
HS. examples are direct copies.
JB. HS - please mention changes that you've noted from today.
HS. summarises.
JB. if HS does these change, then we have an agreed "requirements doc" - can HS do changes by middle of next week?
HS. can do.
JB. who wants to help build the lexicon?
HS. happy to keep working on this (Sylvie and Andrew have helped) - but I can't do much in June/July due to commitments, into Aug.
JB. does someone else want to make a start on the list?
HBj. I volunteer (but on leave for a few weeks).
JB. may be a team of three/four - but will anything happen before September?
HBj. what about Natasha?
HS. i think she volunteered.
JB. i'll check with her.
JB. can you cross compare the draft list with the requirements doc?
HS. sounds OK.
18 June 2004