Agenda in e-mail list archives: http://lists.w3.org/Archives/Public/w3c-wai-eo/2004OctDec/0029.html
Shawn was the keynote at HighEdWebDev 2004, eMergingVisions in Rochester,
NY, USA on 11 October and has a list of references that can be posted. http://www.highedweb.org/2004/index.html
SH: Many in the audience are commercial or industry or gvmt even. Hadn't
spoken to Higher Ed. and was almost "shocked" that almost everyone knew what
a screenreader was. Few had successfully implemented accessibility. Few knew
about WCAG - knew about 508. One guy implemented Quick Tips while there.
AA: Apart from difference between WCAG and 508 - similar to problems here -
common term, each university has someone who works with disabilities.
Familiarity to tools is common and meeting students needs. Not knowing how to
actually do it is also common.
SH: still having trouble with the business case. Small number who believed in
it but had trouble telling others. Wanted to avoid getting sued.
WD: Agreed - will be a big part of what is discussed next month. Everyone got
interested and developed accessible template. Did damage to what
accessibility meant.
JB: Boring templates?
WD: Yes - talking to people making policy. Enthusiasm but not ways to get
done. Will start with Business Case
WD: In California State University system
WD: CSUN is as behind as everyone else (one of the campuses)
WD: Have knowledge in faculty, but not implemented on policy
JB: Other countries? Higher Ed system
AA: WANAU - http://www.monash.edu.au/groups/accessibility/
AA: In Australia - set up a group for Web across university sector
Doyle: Never been impressed with whole system being together
HS: One U. rather frequently and another not so frequently.
JB: focused on businesses or carry over?
HS: Just had closing festival for "Drempels Weg!" (away with barriers!) - not
many people from universities - mostly companies. Technical schools.
Technical multimedia - hope to spread
HBJ: Improvement - permanent on agenda at U in Copenhagen as part of
usability cause. 2 or 3 hour session - exercises about accessibility. Admin
don't see that much understanding. A big impact.
RC: May remember new look - to be working in the next weeks. Final agreement
in government.
JB: More excitement from Italy then
RC: Too many people saying too many different things. For example- run to the
logo. Try to put a WAI or Bobby logo or to make everyone see it's easy - I
managed it. Even in some university there are some people who are making
business not education.
RC: Afraid not only Italian problem. Run to the business because of new law.
Need to make everyone understand what the new law means. Should be cultural
problem not business. Not short time aim.
JB: Maybe business and cultural.
JB: Need to try to help orgs. get past superficial understanding. Good that
they are aware and aware of technologies - but not aware enough of resources
and how to do serious implementation. Or not just dull and boring.
JT: As a student I echo and agree with what's been said.
JB: Promo campaign that I discussed, maybe that some done in US can be spread
across other countries.
JB: Customized - here are some resources.
AC: Interviewed on radio about Web Access Toolbar - created by IIS.
AC: Another in Spain with W3 office - doing standards tour. Setup bus
stopping at Univ. in Spain.
JB: Talked about in office - make sure have literature in both languages.
First bus tour.
RC: In Italy we have the Italian version of the Accessibility Toolbar
JB: HS - anything else about "Drempels Weg!" (away with barriers!) closing
ceremonies?
HS: Was done by org. just outside. Festival org. So not that many people as
had in the beginning.
HS: Foundation and other partners - gathered in building nearby. Groups from
large organizations - 1.5 hour talk on accessibility.
HS: All agree necessity - signed declaration to work on in next year. Not
many have accessible websites.
HS: Was very nice - came out that should be at least more than intention.
Should not be difference between two. Press coverage.
AA: Extra WRT Universities: In Australia we have Regional Disability Liaison
Officers for Universities http://www.dest.gov.au/highered/programmes/rdlo.htm
and each University has a person or team e.g. http://www.services.unimelb.edu.au/disability/index.html
JB: Any other?
AA: People in Japan just released. So now European languages and two Asian.
AA: Germany and Sweden interested as well
AIS Web Accessibility Toolbar for IE - http://www.nils.org.au/ais/web/resources/toolbar/index.html
and Language Versions (Italian, Spanish, French, Japanese and Korean) listed
at http://www.nils.org.au/ais/web/resources/toolbar/index.html#languages
JB: Help people decide which evaluation tool to use. Shadi had jumped into
this after brainstorm with Judy. Came up with full blown draft.
JB: Intro on general thoughts - strong disclaimer (W3C can't endorse or
promote tool). Reviews page
JB: Springboard to look at audience and goals first
JB: Brainstorm requirements then look back at document - have specific
questions at that point
JB: How would use document, read thoroughly or have in hand to skim, other
audiences if broaden focus. Reconfirm if want as part of resource suite.
JB: How do we want to define audience?
HBJ: Tried to read carefully. Very good, but if have to have broad audience.
Language is not very simple. Some of the sentences are at a high level. Not
plain English.
JB: So possible requirement would be that the document is understandable by
those without necessarily having strong technical background.
HBJ: Find that we use "review" or "evaluation" - change of vocabulary?
JB: Audience may be at a basic level of tech.
AA: Agree in part, basic level of accessibility. But technical, agree with
groups - web designers should be technical already. Other groups - manager
could potentially have low level of understanding. Want to not to pitch too
low for technical or too high for university person
Wayne: May disagree a little. Three people
SAZ: Explain user roles - people to use: developers, reviewers. Managers
assessing what's presented so they might not have same need. Having a good
heart and having to get job done. Aimed at people getting job done
JB: Basics for people considering tools and technical considerations?
JB: Two different sections?
Wayne: Could see doing that but see need for advanced user
Shadi: Helle - was problem language was too technical?
HBJ: Sentences too long in some places. Not necessarily too technical - but
high level English.
JB: Not plain English
HBJ: Yes. I was thinking if user requirements. Some interested in document
would also be people who are getting some type of software. Not a huge
company doing huge website, but address people doing smaller things at
smaller orgs. May not have huge group of designers, etc. May just be one
person.
SAZ: Clarify - use roles. User requirements - not about people using doc. as
people using tools.
SAZ: Systems team or administrator - setting up tools. May not be purchasing.
Help decision makers select tools and see how other orgs. are set up.
JB: Let's stick with basic audience for this
SAZ: Yes but User Requirements aren't users I had in mind.
JB: How did you see audience?
SAZ: Thinking more of people who purchased evaluation tools.
JB: Procurement person?
SAZ: yes
JB: when see concept and think of what we already have. This in addition. who
do you most want us to be speaking to when we give advice on selection?
Almost dichotomy with people new to tech concepts and people who need more
advanced orientation.
JB: Every time sent someone to list of tools have come back saying "what do I
do with this list?".
HB: Impressed that this seems to indicate that it is a shared responsibility
among different groups. I like this organization myself.
RC: Agree
JB: Want doc to be able to be read with a wide variety?
HB: Yes
HS: Yes - Not just web developers. Problems with other features - security or
technical aspects. Accessibility part of bigger aspects - assurance.
HS: Some tools are very expensive. but 2nd document maybe?
JB: Didn't mean separate just sections
HS - mention something about procurement for managers. Another document -
business case.
HS: This one just for reviewers and developers.
JB: Could be addition to implementation resource suite.
Doyle: Not aiming at people working from home making a site?
JB: They need advice too - we get questions from there.
Doyle: Agree with that - mainly aiming at professionals and business?
JB: What do other's think?
SH: Need to acknowledge broad audience but need to choose a primary
audience. Person at home not going to be purchasing expensive tools. Very
different. Would probably use free tool or one on already purchased tool.
JB: Mainly talking about purchasing expensive systems?
JB: How many free vs. paid and sophisticated?
AA: Java based tool - like an annotated version of page - like Bobby, run
multiple tests, etc. only in Spanish
AA: Expensive tools tend to be robotic spidering tools. Generally inadequate
for testing for accessibility.
AA: Guidance towards buying tool - or guide toward suite of tools to check
complete picture.
JB: Moving away from who is audience.
JB: Leaning towards audience that is in larger org. that may have multiple
roles of people involved in decision to acquire evaluation tools. May need
not so technical version, but do want to provide info for more technical
audience.
SAZ: Wasn't thinking of larger orgs. Someone who wants to evaluate website -
has a target in mind. Has a basic idea of software. Someone wants to install
and use. Generally not a newbie on the web if doing this. Web developer from
home,
CS: Many have come to point where you want help doing evaluation (with a
tool)
JB: Disagree some expect that it can be done automatically and look for tool.
AA: experience more with what Judy said - expect a tool.
SAZ: Not talking about Accessibility expertise, but general web experience
Wayne: Who would be looking would have some real ability technically and
experience.
HB: or have people to depend upon to provide.
Blossom: Read in terms of many different users - only place where got lost.
Descriptions - some are hard - seemed focused on programmers
Blossom: Larger, wider audience
audience - liked that
JB: Structure worked?
Blossom: yes
Doyle: even if not working for large org. need help with this.
Doyle: Someone with blog doesn't need all of this stuff.
Doyle: even if technical be usable. What technical people want - something
usable - not really an audience question
JB: Summary statement we can agree upon - turn to whatever audience we think
of - what do we think they need to hear? How likely to use this?
JT: I think these are the different things you might need based on who you
are. What fits into that category.
JB: Would see mapping onto database on tools.
JT: Yes - would be most helpful
SD: Depends on audience - people reading document need different things.
Should decide by price, or what want to know about site. What want to know is
which tool would enable them to evaluate which things?
SD: This more technically this one other things to evaluate. One for larger
sites, one for smaller.
JB: Mapping against existing tools
HBJ: Talking of tools (specific) what about authoring tools? How to
distinguish with something you use with another tool and after process. How
do you show different tools for different stages of process?
HBJ: someone write small summary of this tool good for this and that tool
good for that. Would want list
Alan leaves call
SAZ: Some are evaluation or repair tools. Technical factors - how well fit
into existing environment. Could be extended or elaborated
SAZ: Don't know how much was discussed last week.
JB: Very little - didn't miss much
SAZ: idea from business case would provide different things for them to look
for. Let person choose what is best. Content authors would have different
features in mind. Considering different factors according to ones own
situation.
SH: One organization will usually purchase one tool, not multiple
SH: All roles may be involved in one organization, may be one person doing it
all or many people. Most will figure out which tool works best for entire
organization. If correct not sure how effective to have different people
listed.
SAZ: For some groups would want to see. Content authors would want to plug
into content management system. Someone else may want to have work on repair.
May work to combine several tools, might make sense to buy one.
HBJ: Comments not on structure - level of language. Maybe if rewrite in
simpler language. When I work on my personal site I use what plugs in to my
tools, for checking and repairing. If looking at another site I use a
different free tool. Way to review existing or doing something as
developing.
JB: Approach took in other document. Got initial reaction - spent time
explaining. Break out question links.
SH: http://www.w3.org/WAI/impl/
JB: How envision primary audience, but how do we see being use
DS: Same picture I get myself
JB: Others? Do you see as being educational, for reference or what?
JB: User requirements section - should there be a section, is this where it
should be?
RC: Agree
HB: Belongs up front - put managers first on list.
HS: Term User Requirements - put on users - struggling with wording
JB: User of the tool or user of document?
JB: different term that would capture it
RC: We could say simply "Users"
SAZ: User roles or profiles
HS: Yes more clear
JB: who uses tools - better?
DS: Very clear
HB: Responsibility sharing
JB: Other comments
JT: Would help if 2nd section was in bullets. Break up
JB: How much do different roles effect choice of tools
JB: Worthwhile to do at this point in document? Done as a brief intro - or
after features. Exclusionary? Would help them to focus? Help with flow of
document?
HS: select different tools - 5 different. Real technical managers can be part
of technical section. When more about money can be somewhere else. Need
categories.
HBJ: Task doing not role - where you are in process. Reviewing, developing
JB: Say more - expand
HBJ: When in beginning of process need to look at evaluation tools for
certain aspects. When doing review and evaluation would look at differently
HBJ: Not users themselves but how they use it.
Doyle: roles right?
AA: Think she is quite right. Maintenance, development, etc. will determine
need of tools.
AA: More role than job specification
JB: different types of requirements for tools
JB: Any other questions?
SAZ: Originally wanted to put what type of output would expect from each
tool. Conceptual error messages, et
JB: That would be even more useful than what is here. Have to focus hard to
read narrative description. Want something that takes me to practical
information.
JB: This takes us close to what Justin was saying - having bullets of what to
look for. Feedback profiles
Wayne: If word "web developers" changed to "web development" etc. Could talk
about what you need when doing this.
HBJ: Also instead of splitting - what about putting requirements and
reporting and put under each one.
HBJ: Take tools part and features and what Shadi was saying. Split up. Web
development look for this in tool and feedback you want is this.
JB: Shadi reactions? Able to extract for change log?
SAZ: Very helpful - discussion about type of section and subsections.
Language reviewed. Made more readable. Like approach about putting more
concrete for what looking for. Some examples in graphic form. Mean cross
links from Web Developer to what tool features looking for.
Wayne leaves call.
HBJ: Having it be below developer
SAZ: Repetitive though
HBJ: I'm developing - what do I need to look for.
HS: Do what Wayne suggested - change person to process stage. Web developing
etc. - what Helle said and Wayne's suggestion - in stages
CS: List features below roles and link to full description below.
HS: Better - instead of taking out of other section. Better to link.
RC: Agree
HBJ: Agree
SAZ: think "tool features" should be renamed. Not things like line numbers,
bar charts. Those may be things people would look for. Should those features
be linked to - or put beneath each role.
CS: thinking link to bottom for features - specific items listed under each
group.
JB: Shadi - read back main points from conversation
HB: Validity of markup and link checking validation
HB: Both are important - bad links waste time and bad code isn't usable.
JB: Scope of what we can comment on here is what is covered in accessibility
guidelines. Validity of links isn't part of WCAG 1.0
HB: Something in WCAG 2.0
JB: Wouldn't be a lot to do on that now with this version because just doing
cleanup and adding some material. Once WCAG close to revision can revise
suite to 2.0
HB: I find both needed in document
AA: 1.0 does talk about clear links and valid code
JB: Doesn't talk about link validity
HB: Yes and that's what I'm talking about
JB: Could include as in "look at other factors such as...".
HB: Frustration with broken links.
Roberto leaves call
JB: Many things that frustrate people regardless of disability
AA: If I click on link and get 404 error or if I have an unclear link. If
going to 404 error page should say that.
JB: problem is the fact that WCAG 1.0 does not have precise testing criteria.
Can check with WCAG WG and get opinion. In or out of scope. Can we live with
that?
HB: ok
HB: Valid code next topic
JB: Absolutely in WCAG 1.0. In web developers as report should get.
SAZ: Biggest voice was for 2nd pass at language. Section and subsections to
reflect roles rather than user categories.
3) describe doc structure and usage
4) more practical guidelines to lead to feature. Bullet forms or visual
examples
JB: Anyone's feedback missing?
*cheers* for Shadi
AA: hear hear
SH: Blossom's email - navigation will be covered with site redesign
Blossom: will resend with idea for quick fix
SH: Before redesign is done?
SH: changes to suite probably won't be before new design
SH: http://www.w3.org/WAI/EO/Drafts/UCD/components
JB: Will be presenting Harmonization issues at conference in Brussels next
week. Few things have changed. SH comment on changes
SH: First is interdependent web components. Took out image. Last version had
other design features - changed 2nd image as well.
SH: Images - Would like to get agreement on concept. Will be changing little
images, but expect other's to stay the same. Next heading said Guidelines for
components. so changed to "Guidelines for Different Components"
Blossom: Trouble with 2nd image - doesn't work for me with lines through
computers
SH: That will change.
Blossom: multiple computers doesn't help me understand multiplicity
JB: One computer series of shadows
Blossom: graying out?
SH: Need to show that you have to use multiple tools
SH: Would be interested to know Wayne's point of view on subject
JB: What else jumps out for people?
Blossom: Long ALT text - add value?
SH: Most stuff moved and moved back
SH: Mostly done - no images to cleanup. Done as far as I'm concerned.
SH: They are done - so if you have editorial comments send to editors list.
SH: Note if need to be in this version or if low priority or can be done in
next version
JB: Anything urgent needed by?
SH: Today
SH: regrets for next week? Henk.
22 October 2004