W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > April 2000

Re: Please review: proposed agenda for ER/AU f2f

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 21 Apr 2000 12:55:42 -0500
Message-Id: <200004211653.MAA456925@smtp1.mail.iamworld.net>
To: Wendy A Chisholm <wendy@w3.org>, Charles McCathieNevile <charles@w3.org>
Cc: w3c-wai-er-ig@w3.org, w3c-wai-au@w3.org
At 12:42 PM 2000-04-21 -0400, Wendy A Chisholm wrote:
>Charles,
>
>we may want to have some discussion on the ERT with the AU group, however 
>if you look at the list of issues we wish to cover these are addressing 
>basic holes in the ERT.  The list of issues are checkpoints for which we 
>have *no* techniques at this time.
>

Yes.  And the AU troops maybe could help some with that.  Diversifying your
knowledge base is good for brainstorming.

Al

>--wendy
>
>At 12:08 PM 4/21/00 , Charles McCathieNevile wrote:
>>Hello,
>>
>>it would seem to make more sense to do the brainstorming on ERT in
>>conjunction with the AU group. I am not sure how many AU people are coming
>>for one day and how many for both days.
>>
>>cheers
>>
>>Charles
>>
>>On Fri, 21 Apr 2000, Wendy A Chisholm wrote:
>>
>>   Hello,
>>
>>   Based on last week's ER WG discussion the rough agenda is:
>>   Thursday: work through open issues with ERT (brainstorm), set goals, 
>> create
>>   plan.
>>   Friday: joint meeting with AU WG. Strategize, demonstrate tools, plan.
>>
>>   I've tried to fill in more detail.  Please comment.
>>
>>   Thursday
>>   9-9:15 intro's
>>
>>   9:15-10:30 ERT
>>   -Checkpoint 12.3 - Divide large blocks of information into more
manageable
>>   groups where natural and appropriate
>>   -Checkpoint 13.3 - Provide information about the general layout of a site
>>   -Checkpoint 13.4 - Use navigation mechanisms in a consistent manner
>>
>>   10:30-10:45 break
>>
>>   10:45-12:00 ERT
>>   -Checkpoint 13.5 - Provide navigation bars to highlight and give
access to
>>   the navigation mechanism
>>   -Checkpoint 13.8 - Place distinguishing information at the beginning of
>>   headings, paragraphs, lists, etc
>>   -Checkpoint 14.1 - Use the clearest and simplest language appropriate 
>> for a
>>   site's content
>>
>>   12:00-1:00 lunch
>>
>>   1:00-2:30 ERT
>>   -Checkpoint 14.2 - Supplement text with graphic or auditory presentations
>>   where they will facilitate comprehension of the page
>>   -General scripting discussion: when is it used? when can you replace
>>   scripts with  HTML on the page itself?  when is it possible to push the
>>   functionality it to the server?
>>   -Technique 1.1.11 [priority 1] Check A elements for valid text content
>>   @@handled by technique 13.1.1 - verify that targets are clearly 
>> identified?
>>   What else do we need to check for?
>>   -Technique 2.2.1 [priority 3] Test the color attributes of the following
>>   elements for visibility. ... Requirement: Determine color
>>   visibility.@@needs work?
>>
>>   2:30-2:45 break
>>
>>   2:45-3:45 ERT
>>   -Technique 3.7.1 [priority 2] Verify instances where quote markup 
>> should be
>>   used. ... Lots of emphasized text (greater than x words??@@)
>>   -Technique 5.5.2 [priority 2] Check TABLE elements for valid CAPTION
>>   element. ... Requirement: @@
>>   -Technique 6.2.1 [priority 1] Check the source of FRAME and IFRAME 
>> elements
>>   for valid markup files. ... @Adjust Javascript to point inside the
wrapper?
>>   -Technique 6.2.2 [priority 1] Verify that equivalents of dynamic content
>>   are updated and available as often as the dynamic content. ...
>>   Requirements: any actions that change the display must change the
>>   equivalent @@Is this computable in a practical time (cf. NP complete) .

>>   Computer science help needed here. Of course, as in other parts of
>>   document, the fact that the equivalent changes is no guarantee that
>>   equivalent is correct than it is guaranteed that "alt" text for an 
>> image is
>>   correct.
>>
>>   3:45 -4:00 break
>>
>>   4:00-5:00 planning
>>   What needs to be done?  Who is going to do it?  Assign action items.
>>
>>
>>   Friday (with AU)
>>   9-9:30 intros, overview of yesterday, getting people on the same page.
>>
>>   9:30-10:30
>>   Techniques discussion.
>>   Reviewing commonalities between AU Techniques and ERT Techniques.
Sharing
>>   information about open issues and common problems.  How should these two
>>   documents relate to each other?
>>   Refer to the ATAG1.0 Techniques:
http://www.w3.org/WAI/AU/WD-ATAG10-TECHS
>>   and the ERT Techniques:  http://www.w3.org/WAI/ER/IG/ert/
>>
>>   10:30-10:45 break
>>
>>   10:45-12:00
>>   Tool discussion.
>>   Review commonalities between AU and ERT tools.  Share information about
>>   implementations, implementors, needs.  Has AU identified techniques 
>> that ER
>>   has found implmentations of?  Who works with the implementor to see that
>>   techniques are included?
>>
>>   12:00-1:00 lunch
>>
>>   1:00-2:30 Demos and discussion
>>   A-prompt
>>   Allaire HomeSite
>>   Bobby
>>   W3C HTML Validator
>>   Schematron
>>   Tablin
>>   WAVE
>>   others?
>>
>>   2:30-2:45 break
>>
>>   2:45-3:45 Strategizing
>>   What is the most efficient way for out two groups to work together?
>>   We've both been realizing overlap in goals and resources. How should we
>>   handle this?
>>
>>   (proposed draft) ER WG
>>   http://www.w3.org/WAI/ER/erwg-charter.html
>>   The mission of the Evaluation and Repair Tools Working Group (ER WG) is:
>>   to document techniques for creating Evaluation and Repair Tools;
>>   to find tools that implement the techniques and where there are none,
>>   prototype or participate in the development of an implementation;
>>   to assess the implementation of these techniques in evaluation and repair
>>   tools;
>>   to provide a discussion forum to review and collaborate on tool 
>> development.
>>
>>   AU WG
>>   http://www.w3.org/WAI/AU/charter3
>>   To complete the development of accessibility guidelines for authoring
>>   tools, and to perform initial assessment of implementation of these
>>   guidelines by authoring tool manufacturers. These guidelines should 
>> address
>>   how authoring tools can:
>>   provide author support for creating accessible Web documents;
>>   ensure an accessible user interface for authors with disabilities.
>>   Assessment of implementation is expected to allow improvement to the
>>   supporting documents produced by the group, and if necessary to begin
>>   revision of the guidelines themselves.
>>
>>   3:45 -4:00 break
>>
>>   4:00-5:00 Planning
>>   What needs to be done? Assign action items.  Resolve outstanding
>>   coordination issues.
>>
>>   ---Other open issues that could be discussed on Thursday
>>
>>   - Technique 6.4.1 [priority 2] Check for device independent event 
>> handlers.

>>   ... Requirements: Objects must not contain device dependent event 
>> handlers.
>>   @@Does this mean checking Java, Flash, etc? Can we only do this for
>>   scripting? Or prompt the author to check?
>>   - Technique 6.5.2 [priority 2] @@Need something for scripts and
>>   programmatic objects?
>>   @@ is this covered by 6.3.1 (Verify that the page is usable when
>>   programmatic objects are disabled)?
>>   - Technique 7.3.2 [priority 1] Verify that programmatic objects do not
>>   create moving content. ... @@ what about OBJECT, EMBED, and APPLET?
>>   - Technique 9.3.1 [priority 2] Check scripts for logical event handlers 
>> ...
>>   "onMouseMove" remove or replace with ??@@
>>   - Technique 10.3.1 [priority 3] Verify that a linearized version of
tables
>>   used for layout is provided. ... Suggested repair:
>>   If it has been determined that the table is used for layout (see
Technique
>>   5.1.1) then create a linear version of the table by: [@@insert heuristics
>>   from table linearizer - basically replace TABLE markup with text 
>> structural
>>   markup]. The author will then need to check that it is readable.
>>   If it has been determined that the table is used for data (see Technique
>>   5.1.1) then create a linear version of the table by: [@@table linearizer
>>   heuristics? basically, for each cell repeat the column and row headers
>>   associated with it]. The author will then need to check that it is 
>> readable.
>>   - Technique 11.1.1 [priority 2] Verify that W3C technologies are used,
>>   where possible and appropriate. ... Element: ?@@
>>   Requirements:
>>   Check for uses of non-W3C technologies such as: PDF, Flash, GIF images, 
>> JPG
>>   images, proprietary HTML elements (@@other major ones??).
>>   @@link See 1.1.1 for images used for mathematical equations.
>>   Note. I left out JavaScript because there is not a W3C equivalent
>>   technology yet.
>>   - Technique 11.3.1 [priority 3] Check that documents are served per user
>>   preferences. ... Element: ?@@
>>   Requirement: ?@@
>>   - Checkpoint 12.2 - Describe the purpose of frames and how frames 
>> relate to
>>   each other if it is not obvious by frame titles alone
>>   @@ covered by 1.1.8?
>>   @@Suggest that if the FRAME "title" does not describe the frame that a
>>   "longdesc" is needed?
>>   - Technique 13.9.1 [priority 3] Verify that information about document
>>   collections is provided. ... Elements: @@? LINK, A
>>   - Technique 14.3.1 [priority 3] Verify that a consistent style of
>>   presentation is used across pages. ... @@This requires looking at pages
>>   throughout the site. Need two levels of checking: page vs site?
>>   --
>>   wendy a chisholm
>>   world wide web consortium
>>   web accessibility initiative
>>   madison, wi usa
>>   tel: +1 608 663 6346
>>   /--
>>
>>
>>--
>>Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134
136
>>W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>>Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
>>Postal: GPO Box 2476V, Melbourne 3001,  Australia
>

>--
>wendy a chisholm
>world wide web consortium
>web accessibility initiative
>madison, wi usa
>tel: +1 608 663 6346
>/--
> 
Received on Friday, 21 April 2000 12:51:27 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:10:35 GMT