W3C logo Web Accessibility Initiative (WAI) logo | EOWG Home

EOWG Minutes, July 20, 2001


Outdate Updates

JB: Posted minutes of 2001-07-13, with some outreach/update comments possibly missing. Please help reconstruct them if you know of any missing.

Semantic Web Primer

WL: Posted Semantic Web Primer


WL: Conveys how it is different from current web.

People will be able to use the web without even knowing they are using it.

The semantic web will be the same kind of revolution as the web was (and is).

The semantic web will change the means of indexing.

Web of trust allows all transactions to be productive and easy to achieve.

LL: I'm impressed with this contribution.

DS: Has taken to Wells-Fargo librarians, for their education.

WL: The "web of trust" concept EO hasn't settled on yet.

MIT Project Oxygen


JB: Made a presentation to members of this group, commenting on the importance of including accessibility considerations in every area of their work. Will publish those slides. Reconsider how research groups construct scenarios. One issue: how do scenarios degrade when one adds disability into the picture.

Workshop on Use Cases

WL: In device independence WG (IG?), requirements will have "use cases." A workshop on how to write scenarios would be valuable.

JB: User Agent group wants the EOWG work on use cases published so they can reference it.

HB: UA is delayed in going to Candidate Recommendation as SVG issues are not resolved and SVG decision makers are on vacation.

Australian Capital Government

JB: See Andrew Arch's email on presentations he gave, noting the overlap between accessibility and usability concerns.

Netherlands Health and Welfare Boards

HS: The Danish Health Boards and Welfare has 14 agencies, and are spending much money on web development, They've decided to require accessibility. Assert that companies must be certified, and certifiers are to be Henk and Eric. This took EV and HS by surprise. They are now planning how to do this, and for how long.

JB: This is news. The appendix we're discussing addresses part of this issue. Other parts include how to address coverage, turnover of staff, level of compliance, what fraction of sites' pages, exceptional pages.

WL: Opportunity for graft is present!

LL: Similar to US Section 508.

JB: Different as in 508 the government agencies can only buy from certified hardware and software sources, without provision for outside expert certification.

HB: Can you decertify for non-compliance?

HS: Not law-based, only as motivator to build accessibility into pages.

JB: Some of what we are building can support this. For someone to try to certify an organization, some training would be needed (training resource suite). Also Some internal process to assure following proper web design business. Also needs a comprehensive internal review process. There was a company developing a testing process for certifying individual designers: possibly all persons generating pages would need this training. Re-certification annually would be possible.

WL: Move from academy of surgeons to more general group. [Ed: from experts to general developers.] HB: [Ed. ... is text added in editing by the scribe.]

LL: Most companies wouldn't even consider it. Own experience suggests that this is probably impossible. All that is needed is that the end result [Ed: according to 508 requirements] is accessible.

HS: Also demand that all websites be accessible, as reviewed by an external expert.

LL: Where is the funding coming from?

JB: Some internal process requirements could be dropped if a company has an external review and certification.

AA: A third alternative: partner with other companies on tender/quote to provide the accessibility requirements.

JB: Caution: A primary company without expertise who brings in a third party as "cover", that third party has huge and painful burden to wrestle site to make it accessible, without help from the primary company.

LL: The legal exposure to the certifier seems a high risk.

WL: Internationalization issues are important. For example, where he comes from "A camera used to record a speeding violation would be shot by five shotguns the first night."

EV: We have a much smaller market.

HBj: Make clause in development state tender: "Document your accessibility compliance."

JB: Contract "boilerplate" is included to have standard, repeated language of every state/government contract. It was hard to get that into state language 10 years ago. Section 508 will be one such example.

HBj: How do companies document how they are providing this accessibility?

Business Case for Accessibility

LC: Submitted comments on low literacy level.

HBj: Also submitted comments.

JB: Action to check on bounced message from HBj: Send whatever evidence, preserving expansion of headers, as way to find out how messages are distorted, reported as undeliverable, or otherwise problematic.

JB: Propose for resource suite. We try to call it one document, sometimes many. Wonder if we have two documents whereas the current contents has:

1. Auxilliary Benefits of accessibilty
2. Demographics
3. Organizational Policies
4. Evaluating Websites
5. Cost of Implementation
6. Legal Requirements
7. Selecting Authoring Tools

JB: Separate the Business Case from the Implementation Suite:

Business case would include [Ed: at least]:
1. Aux Benefits
2. Demographics
5. Cost of Implementation
6. Legal Requirements
Implementation plan would include:
3. Organizational Policies
4. Evaluating websites
5. Cost of inhouse training, include using
7. Selecting Authoring Tools

LL: The business case would help her going to management.

AA: Support this, there is value in this split.

HBj: A good idea. Now seems lost in the ordering and detail.

DS: Good idea to get something out quickly.

WL: So long as the breaking up doesn't interfere with the creation. Fear: model of " how sheep reach through fence to get same kind of grass on the other side."

HBj: Some parts may need to be in both.

JB: Not sure, but expect that this would make certain sections easier to write. The current navigation is not very effective. Expect it would not be difficult to separate.

WL: Only JB can change the navigation items consistently.

LC: Agree that breakout will help.

HB: Split makes sense.

HS: Enlarge intro. Within one or two screens should get an overview of what to do, with links down to subject details. Or split up.

EV: Agree with HS, make intro clearer.

HBj: Need site map. The sample implementation plan for accessibility is currently same as appendix.

JB: That duplication eeds to be removed.

SD: Split.

JB: Summary: Most support split. HS and EV concern for intro. WL concern for getting revisions done. Will outline steps to split apart. Guess this about three hours of work. Then have assurance it is doable.

WL: Concern -- Too many things in priority pile. Suggested split month ago. Hopes this won't stall. Andrew has addressed the "how." The "why" hasn't recently been addressed.

JB: If document split to business case plus relative appendices, which would do we do first?

AA: Implementation first Agree: LC, DS, LC, WL, HS, EV.

WL: Legal case has been resolved in policy, such as 508. The implementation piece is effectively done.

JB: Action: group wants to make sure to finish the benefits piece. Also focus on implementation plan pieces. Do another mini-step of outlining split. Do not abandon business case while working on implementation plan

HBj: Finish the AA work, link to it.

JB: Propose to make the Benefits piece stand-alone for now. Eventually we may choose to wrap it into larger work. If we put it in the annotated resources, that exposure and promotion is valuable.

HBj: Can use it to talk with people about why to do this.

JB: Move ahead the benefits piece. Reflect on the completion of the AA contribution as a stand-alone piece, for next four or five months at least.

JB: Action: Finish benefits. Focus on implementation, regardless of split.

Comments on Evaluating Web Site appendix

JB: Met with Wendy Chisholm. Some review activity on "simple review" section.

Evaluating Web Sites for Accessibility: (Appendix to Web Accdessibility Implementation Plan)


JB: I have worked most of the change log issues into document.

JB: Caution from Wendy: test with plug-ins turned off belongs in the comprehensive section, not simple.

AA: Agree: plug-ins go in comprehensive review.

WL: Hiring issue: Design for customer, rather than simulate issues. Conduct simple review needs real users with disabilities.

JB: Review document. Simplified intro. No single tool. Give tips. Now have new section 2. Goals and expectations for review.

LC: Could put goals and expectations in intro, so that simple and comprehensive is immediately clear.

JB: Add discussions of: 1) disabling plug-ins, and 2) hiring policy.

JB: Add goal that web site will maintain a level of accessability.
Debatable issue: evaluation of page in static form.

AA: Discuss process of maintaining ongoing accessibility. What processes should be put in place in organizations.

JB: Add discussion of this, or link to ongoing monitoring, following Gregory's comment.

[Ed. GR: "to provide assurance that a Web site will maintain a required level of accessibility."]

HB: Not just current documents, but legacy documents that will never become accessible. By default assume they are not. So assurance needs to be "maintain or achieve a required level of accessibility."

WL: New pages can be identified by timestamp. State that each document needs a timestamp. Policy with updates should be to apply new accessibility requirements whenever a page is updated, and add its timestamp [Ed. and possibly revision level too].

JB: Few pages currently include timestamps. Some pages have fictitious ones. Legacy pages are tricky. Does it contradict Gregory's concern?

JB: Action: Not commit to include GR's added goal. Will take on experiment to address GR's comment.

Simple Review

JB: Expect use of few tools. Reviewers don't know [Ed. HTML] code. May not have used assistive technology. Limited expections, just to find huge problems with site. Grab more than one page. Will likely miss some browser tricks. Some tools are more help than others.

HBj: Quick tips card on simple menus might help.

AA: Would expand the simple review section: Split current item 3 into fonts separate from colors.

JB: Make bulleted list.

WL: Phrases from disability rights movement:

"People first,"
"Nothing about us without us."

Add "define the client."

JB: Does this simple review address those clients without anyone with disabilities. The super-capable person as a reviewer is a risk. [Ed. as that reviewer may take too much for granted].

AA: The person from a disability group may be testing for the wrong things, doing best they can with limited resources.

HBj: Agree, [Ed. with false assertion] "you don't need people with disabilities at this stage." They may soon realize they need to get more people involved.

AA: Simple review only gives an indication, the flavour.

JB: A structural problem: simple review: is not basis for determination of conformance. Add "this review has not included people with disabilities, there may be key issues missed. Rei-enforces disclaimer.

WL: Get the "nothing about us without us." concept therein.

JB: Even a simple review is to get folks started. Incomplete.

AA: Capture them first.

JB: Preparation for a "proper" comprehensive review.

WL: Dealing with people's behavior without understanding, is a risk.

JB: Add a strong caution against leaving out persons with a variety of disabilities.

JB: "Quick tips for review," [Ed. as suggested above by HBj] would be promoted at the expense of the comprehensive review.

JB: Action: Rename "Simple Review" to "Preliminary Review." [Ed. Page designer/content provider should] do Preliminary Review before bringing other people in.

AA: This will simply find some issues and fix them before getting them into the comprehensive.

WL: The network is the computer.

LC: "Run a web checker, such as Bobby, the WAVE, A-Prompt." Expand acronyms. (also HPR).

HBj: Add country check.

EV: Nothing now appears about validation tools.

JB: HTML and CSS validators all require knowledge of tools.

WL: Same reason we haven't included TIDY.

JB: Add disclaimer, not generating valid HTML.

EV: Don't like disclaimers.

JB: Psychological Judo: disclaimers become motivator for people to use the comprehensive review.

DS: In large company, top-down "use company resources, and follow our standard" can bring everybody into the concept.

JB: Alternative: from experience working English as a Second Language with Chinese (Cantonese), hospital practice was to request anyone knowing the language to come to emergency room to help interpret, worked badly as often the only reponder didn't have medical experience to properly do that. Need to give such people support, [Ed. Using a method that is] recognized to work.

DS: How get people involved without being abusive, an enterprise who wants to implement will consider its resources and their training.

JB: Expand section on having people with disabilities within an organization doing the reviews, including making sure they get adequate training, recognition, and time to do the job, etc.

Future Meetings

Berlin September 18-21

JB: Tentative: to include Information day and EO WG meeting. Have not been able to start process for identifying hosting. Will work this in next several days. Close to deadline (8 weeks.) Haven't promoted it on list.

JB: Who will come: HS, EV, HBj.

LL: How can LL help?

JB: Need contacts in Berlin for potential hosts.

ER and PF in England October 3-5

JB: Information, not propose EO there too.

Washington DC during week starting October 8, or 15

JB: Push for a EO WG meeting in Washington DC.

JB: Meeting in DC either week Oct 8 or 15: Who will come: HB, LC, HBj, DS, AA (longshot, more likely than Berlin), SD (maybe).

Meeting in Melborne Nov 12-14

AA: You would be welcome to come to Australia.

JB: Who will come: AA, HBj, JB only if EO were there, HB (wish)

HBj: On vacation for next three meetings.

EV: On vacation for next three meetings.

HS: Gone for next six meetings.

Next teleconference meeting July 27

July 27, same time, 8:30 to 10:30 AM EST,
Phone: 617-252-7000

Copyright  ©  1998-2001 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.