W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 14 April 1999


Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca

Date: Wednesday 14 April 1999

Time: 3.30pm - 5pm Boston time (1930Z - 2100Z)

Phone number: MIT Bridge, +1 (617) 258 7910 - note different bridge


Review of Latest Draft

The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990413.

From the previous meeting:

Priorities of checkpoints from 2.7.3 to end

Guideline 2.5 - Never remove accessible content

Raised by Lauren Wood: http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0260

Do checkpoints in section 3.3 and 3.4 need to be implemented "natively", or can they simply be satisfied by providing an interface for assistive technologies?

Raised by Bruce Roberts: http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0023

Raised by Charles McCathieNevile: http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0045

and in http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0244

Raised by William Loughborough: http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0008



Action Items and Resolutions


Guideline 2.5

JT Unresolved issues: Expecting the author to know HTML and know what can be removed - good thing is that gives human judgement, but requires knowledge. We had a proposal that nothing be stripped out, which removes the ability to take out things that we want taken out. We want to say don't remove stuff that we need, don't add junk, don't alter it in a way which affects accessibility. This comes from access structure which may be deprecated, but we want it until aa better thing comes along

GR It is both forward and backward looking

CMN: A couple of things we need: tools shouldn't remove what they don't understand -= a last resort, but should be in there.

BR It may be a lot od work to carry that if the user edits - may become infeasible

GR A tool wilkl have to check against a DTD - if it doesn't recognise the stuff, what does it do?

WL: That's fine if you are doing the authoring, but if the author doesn't know the DTD it won't work

BR: May work with tag-style, but not for PDF upgrades (for example). The problem is not always soluble. An analogy is reading file formats produced by future versions.

CMN: The W3C answer is probably to check namespaces and DTDs, but only works online

JR The problem isn't so bad if it is just elements and attributes. Maybe we should not worry about PDF - it is a non W3C spec.

WL PDF is on the web and pervasive

JT But may not have any accessibility stuff

CMN It certainly does

GR It should be in the techniques

BR So we restrict it to when importing content which follows a w3c spec...

JR "..don't drop unrecognised content"

JT Never remove unrecognised elements or attributes in a W3C specification. Without alerting the author?

JR Alerting the author is a User Interface issue

CMN Alerting the author has to happen, but the author may not be able to give any useful feedback.

JT For an under-the-hood tool it could be frightening to authors

JR Batching the alerting could improve it

JT Do we need to say "without alerting the author" in the checkpoint?

WL: The reason we want to do this is someone might put in marku[p that helps proomote acceessiblility

JT This tool may not recognise a given version, and we want to preserve any accesssible content there is

GR Is this the checkpoint that Daniel has used the example of tables for?

CMN Yes.

GR The crux is the process thing. We want to get across the user control, and the requirement not to remove things. Right now it is a negative checkpoint - maybe if we make it a positive checkpoint we will have an easier time

JR If the user doesn't know what is underneath it will be automatic or it won't happen. We tell the tools not to remove unrecognised markup unless the user says it is ok

WL What if you just have 2.5.1 and make the "known" updateable - make a way to update what is known.

CMN: I have half an idea that this is mostly here in 2.1 and 2.2. Propose we go back to read those sections and discuss it on the list.

BR Agree

JR Tools should be upgradeable to new DTDs

JT I think one of the reasons this seems so sparse is that we wanted to get at all the sins of conversion tools. There were a large list that we couldn't articulate - adding junk which is done by some authoring tools, altering the structure to mask what was good, interfering with authored stuff.

CMN I think some of the stuff has been done now. I think we should take this to the list.

Action CMN: Write a proposal to deal with 2.5

WL/JT: Please respond to suggestions on the list.

Action WL: Write a proposal to deal with 2.5

Action JR: Write a proposal to deal with 2.5


Refer to priority definitions.

Proposed: P1


Proposed: P3

JT There was some feeling for a 2

JR THere are some important things for people to think about - maybe gives a casse for a p2

IJ What does emphasise mean - how can it be verified?

JR Mention it

GR My reading is that this is broadening the exmples

WL Chagne emphasise to discuss?

IJ In WCAG there was a decision not to emphasise the universal benefits

JR This is under selling

CMN I think this is a different case

Resolved: P3 - change word to discuss

Proposed: P1

IJ This is also in UAAG - do we need it here?

CMN Yes.

GR I think we should have it here.

*WL leaves

BR This is needed here regardless of UA

Resolved: P1

Proposed: P1

CMN At the moment we will only refer to W3C recommendation. I suggest we cross that if we come to it.

Resolved: P1

Proposed: P1

Resolved: P1

Proposed: P1

BR Issues with that as a checkpoint. Trying to think of what it would mean for a presentation package in drawing elements where there would not be an equivalent

CMN Waht kind of elements?

BR Eg a background image

JR Would be followoing WCAG guidelines about textual equivalents

JT If you are using a clip-art file it is covered by another guideline

BR If they are meaningful content...

JT If they are decorative there needs to be some identification

GR eg Horizontal rules

CMN You might have an image with a long description but no alt text.

GR If I drop in a black background I want to know that it is there

BR What if I put in a blue background

JT Then there needs to be, somewhere, text that says blue background. The author needs to have access to that information.

JR Doesn't need to be displayed

BR How does this differ from 3.4.1

GR If I get a dialogue box for colour choices I get a set of coloured boxes

JR I think it is covered in 3.4.1

JT Here we are talking about the display of the content rather than the interface elements. here we are talking about something which will be seen somehow in the markup. Eg I can't see the blue background or the pretty horizontal line - I need to have enough alternative content to know that it is there.

BR I'm thinking of presentation pages and not sure how to present an equivalent for all elements

CMN I think this and 3.4.1 belong in the same guideline

GR If we put media-dependent content in here? Covering embedded sounds, etc.

BR I don't think that does it?

JT is your difficulty in where do you get textual equivalents from?

BR Yes. How far do you go.

JT If it was done by another author then they should have given equivalents. If it is done by the current author, they can put an equivalent in.

CMN Where it comes from comes out of other parts of this document and from WCAG

JR If we have "a big bitmap" it is not conformant with WCAG

discussion of background image as an example

BR This sounds very burdensome for desktop apps.

JT The challenge here is different to WCAG. Here we are assuming that the author needs to know what the object is beyond its function.

BR I can understand the need for it, but it feels difficult to do.

CMN: Propose - P1, and write techniques

Action BR: Send some sample problems

Action CMN: Write techniques

Resolved: P1

Proposed: P2

GR Would push for a 1.

JT Would push for a 2

JR How do you do it otherwise?

CMN Slowly

JT Could be done by an add-on tool

GR This is a universal design feature. Goes to the idea that "structure has meaning"

BR Without this it is impossible?

GR Very difficult

CMN So we say P1 - to satisfy this allow element by element navigation, and ask for more for extra credit

BR Should we break it into two checkpoints? So we relax the meaning of the term structure in the techniques?

JT Do we have too many P1s? Does that water them down

GR We should leave it until we have assigned priorities

JR Also we ahve taken out a lot of P3s...

Resolved: P1. Techniques to explain that element by element navigation will (minimally) satisfy this checkpoint.

Proposed: P2

Resolved: P2

Proposed: P1

Resolved: P1

Proposed: Technique or P3

JR Technique under a new checkpoint, or expanded 3.3.1 which encompasses multiple documents

BR Could be a technique for multiple checkpoints

Resolved: Technique

JT One thing that seems to have dropped out is user interface elements that are not part of the content, but part of the user interface - this is where this came from

Action JT: Discuss this on list

Meeting Closed - 4.30 pm

Native implementations

deferred to list / next call

Merger of 3.2 and 3.4

deferred to list / next call

Native implementation of 3.3, 3.4

deferred to list / next call

Merger of 2.7.2 and 2.7.1

deferred to list / next call

Abstract, Introduction

deferred to list / next call


deferred to list / next call

Copyright  ©  1999 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.

Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile