EOWG Minutes 15 October 2004 meeting

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

Other Comments

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

Evaluation Resource Suite

Background (from agenda):

Minutes:

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?

Tools Discussion - User Expectation

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.

Other Approaches

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

EOWG Minutes 15 October 2004 Meeting

Agenda

Attendees

Regrets

Outreach Updates

Other Comments

Evaluation Resource Suite

Background (from agenda):

Minutes:

Tools Discussion - User Expectation

Other Approaches

Related Topics

Overview pages

Background (from agenda):

Minutes:

Next Meeting