CMN: Is meeting today to talk about a forthcoming accessiblity meeting in Australia.
JB: for WRNI gave a live radio interview on ADA and web. Mentioned that there is a recent US DOJ friend of the court brief addressing Web accessibility under ADA. Haven't seen final ruling.
JB: 1st item on the agenda is the evaluation of web sites piece. Based on what we discussed and what was on the thread, I updated the draft on Friday.
JB: We are getting more dialog through the list, but how can we close issues on the list instead of just raising them? There are about 15 issues on the list such as Jean-Marie's suggestion about mentioning the issue of hi/lo resolution and scrolling, a strategy for comparing the visual presentation with the auditory presentation, and whether the whole site should be reviewed or is it allowable to evaluate representative pages.
JB: Does anyone have any general comments?
There were no comments
JB: Jean-Marie suggested looking at a page with both high and low resolution monitors.
JMD: A user may have to scroll when a page is displayed on a low resolution monitor - this can be a problem for people with disabilities.
DS: I agree
JB: Is it because the lines don't wrap or what?
JMD: Yes, if the site were designed without relative measuring - it won't be correct in low resolution.
JB: Can't you determine this by using a screen magnification program?
JMD: No, it's a problem in the design. If you look at it in low resolution and it doesn't display properly than you know the page was not designed properly.
CMN: if you use "Close View" you can magnify the screen 4-5 times and see what it would look like with low resolution. It also allows you to look at it with high contrast. JMD: Its not a magnification problem - if you design a page to 640 resolution and then display it on a low resolution screen it would have to be scrolled.
JB: Is this a preliminary thing to do or in the evaluation section? JMD: Its easy to do but I don't know where to put it in the document.
CMN: If a page is designed to 800 X 600 and displayed in low resolution it can be a printing problem - it's a general usability problem.
JB: here's a framework thought: I asked the WAI domain staff for feedback. The lead editor of UAAG said that our doc is a mixed bag between accessibility and conformance to WCAG Level 1.0. We can sharpen the focus by making Section 3 be conformance with 1.0. The preliminary review would highlight problems but not necessarily with regard to the checkpoints. Jean-Marie's suggestion would help identify whether there are overarching design problems.
CMN: I'd like to put it into 2B - say something like "Shrink the browser window to 1/4th width to get an idea of how your page would look on a low resolution browser."
JMD: That's a good idea
JB: Does everyone like that language?
JMD: Yes
AA: Is 1/4th the page the right size? Maybe 1/2 to 2/3 is better. Maybe we should go back to screen resolution.
JB: Jean-Marie what should it say? Set screen resolution to 640/480 and observe whether text, images, tables, etc., display properly?
AA: Ask is there horizontal scrolling?
CMN: Should look at lower resolution that 640/480 - if a page is designed for that it won't reflow for a lower resolution.
HB: the lowest resolution on Windows is 640/480.
AA: For some applications you don't actually get 640/480 though.
JB: We want to describe quick and dirty tricks for checking accessibility on different browsers.
HB: Its important that it gets fed back to the responsible company to confirm or correct input on how to check for accessibility.
JB: Lets get this as far as we can and say that some of what we are asking page developers to do must be figured out by the person doing the evaluation. Is set the resolution to 640/480 OK with everyone? No disagreement.
JB: Next item is the comparison of what is presented visually with what is presented auditorily. Do you tell people to compare? Judy reads guideline - then asks Can people who are looking at the page ignore the visual information while they are trying to evaluate the auditory?
HB: Suggest that they listen to it with their eyes closed and then verify that they are the same.
JMD: I'm OK with that.
JB: How about the next one - should we make it mandatory to check out the entire site with one tool?
HB: This has to be an option because there is so much old stuff on some sites.
JB: You can still sweep the site
HB: It's a god idea to check as much as you can
JB: Should Section 3 explicitly be for evaluation for conformance to 1.0? If you've never looked at some pages, can you claim conformance?
AA: Its impossible on many sites. A practical impossibility. Maybe we can expand and say that pages to be evaluated have to be selected for every sub-site.
JB: Can we play with that idea? The language says to identify the base URL or identify a page selection...Can we define the selection better? Doyle, is there nay language which would help you sample pages - a method that would generalize to other sites?
DS: Its really terminology that's the problem.
JB: would the terminology mean the same thing to Wells Fargo as it does to others?
DS: I'll try to figure that out - but I think the terms are widely understood.
JB: We ID'd two classes of evaluation - the whole site or some pages. Is there some way we can get better control on large sites?
HB: Suggest that they evaluate all the index.html pages (the node leaders) or overview.html.
AA: An index doesn't necessarily mean it's a major part of the site.
JB: There are different ways of slicing a site. Suggestions for rigorous selection of pages:
JB: for Subsection1 of Section 3 how should we do this?
DS: We need to validate acceptable ways to slice it up
JB: We need to give the ways to do page selection
DS: We need to change the definition of entire web site - any enterprise will have many web sites within a web site
JB: We agree on that
HB: If there are disparate designs under your umbrella the eval needs to be applied to each part.
JB: should we drop entire and define a rigorous way to ID pages for evaluation?
HB: Yes
JB: do we need to add to the ongoing monitoring section? Should it be there too?
HB: Get rid of entire in that section too
JB: we should define page selection more rigorously
CMN: I'm leery. How can they claim that the site is accessible if they haven't tested all of it? They need to acknowledge that they have only tested a sample (a representative sample?)
JB: You mean they should disclose that?
CMN: Yes
HB: Something like "We've sampled X% of the web site and it is accessible"?
JMD: We disclose that information in a report - its good to do this. You can have a representative selection but its not the whole site.
JB: we need to double check in sections 2-4 that we are consistent.
HB: Start scribing 16:54
AA: Type selection text drafted. Don't role website and selection together.
JB: Don't keep the exclusion. Under sections 2, 3, and 4.
AA: The Wells-Fargo website. It may have subsidiary sites with own designs. List which parts conform, which don't. Take responsibility from top-down. May only look at sub-set at any point in time, and have someone responsible for that.
DS: A large enterprise might be looking at a transformer to work on all web sites to make them conformant. A costly solution that people might not accept. The transformer (knowledge management) would resolve ADA issues.
HB: Consern that transformer would lose information.
DS: Some large organizations are going that route.
JB: Look at subsections 2, 3, and 4. based on "web site" expanded website selection.
JB: whole site.
AA: Handled OK.
CMN: You may have situation where early selective reviews, like Lotus data base, collect results for evaluations. After years may have assessed information on most pages.
JB: Qualified, not generalizable. We're seeking a minimum for what reviewer should do.
CMN: Transition over time: keep evaluations with (versions of) pages.
JB: We need to keep this simple. Add considerations for particular contexts: "When evaluation/verified conformance of entire website is desired,"...add the evaluation records.
CMN: Goal 100% accessibility evaluations. Won't happen.
JB: What if the presumption for evaluation were on entire website. Large site could disclose their choice to do selected sample.
DS: Works,
AA: Is this too hard? We want big sites to do this. We need to give them a practical, not a theoretical requirement.
LL: What would a company see? We don't know if some pages are accessible yet.
JMD: We try to define precisely the standard for evaluation. The person in charge of an evaluation must decide what to do, to disclse, to claim for conformance. We
CMN: Re disclosure: a representative sample is not the same as complete coverage, can't claim.
JB: Propose as default: assert for entire website.
JB: Evaluation Sect 1 & 2, combine, either entire web site, or selections. For page selection, identify method used. Caution about broken assumptions.
JB: Troubled by only running on subset. Some tests should be on "as many pages as you can."
AA: Grammatically correct.
LL: "Ain't" is understandable.
CMN: English is usage based, not rule based.
JB: If spelling and grammar checkers, try Wendy's CLAD test. Will add pointer to this. Test assumption on page selection vs "as much of the site as we can".
LL: Remove spelling and grammar checker.
LL: 2.3. Remove again the reference to entire website.
DS: 3.1. Coordination problem on million pages with multiple browsers.
JB: Concern for designs from outside consultants.
DS: As this hasn't been done, if human is in loop, unrealistic.
HB: Bobby allows choice among browsers and versions to test pages with.
HB: Selection criteria: Each index.htm and one of common sub-pages.
AA: Manual selection, take pragmatic approach. Items listed under
JB: Leave page selection as is, with a bit more guidance. Take concept of "entire website" into optionally whole site, or selected expanded representative pages.
DS: Reasonable.
LL: A small sample gets careful evaluation. Assert generalization to rest of site.
LL: Need guidance on how to suggest making page selections.
AA: Hard problem.
JB: In broader class of review, option to declare sample as entire, or expanded page selection, on which do less resource-intensive over more pages.
HB: Easier to assert accessibility when pages are valid HTML or XML. Suggest run tidy on all pages that are in selected set.
AA: Commonly recognized problems will use templates, with databases, so need to look at a representative of the generated pages.
JB: If results of evaluation uncover problems with setup/generation of pages, then need to fix the process.
JB: Now that you've found invalid markup, you need to address this on your whole site. Need another section (5) to make this point.
LL: When find pages inaccessible from sample, then fix the generator.
AA: Put this in explicitly, rather than leave as assumption.
JB: Shall we split business case.
LL: Once sell concept then go ahead with implementation.
AA: Agree.
HB: OK.
DS: OK.
Friday 2001-08-03, 8:30 a.m. EST 617-252-7000