WAI PA WG Conference Call

Thursday, 11 January 1999 4:00 - 5:30 PM EST

Table of contents

  1. Participants
  2. Action Items Summary
  3. Stylesheets
  4. Server Guidelines - browser sniffing, Content negotiation, etc
  5. Math
  6. Conformance
  7. Changing priority of checkpoints.
    1. A.5.2 - use sufficient contrast for people to use.
    2. A.10.1 - provide control over autorefresh rate.
    3. A.10.2 Avoid flicker
    4. A.9.2 ensure source of frame is markup.
    5. A.1.6 replace ASCII art with Image and ALT text


Action item summary


What kind of links do we need from GL to techniques

JW:: They go beyond being good practice because they alleviate the temptation to misuse markup. Force seperation of presentation/content. Give user better control over presentation.

CMN:: The guideline about using relative proportions is not specific to stylesheets, but can be done

DD:: Stylesheets can be abused by using ID/CLASS oneverything and assigning properties to thousands of elements which would confuse a client-side and make it difficult to predict what should be overridden.

CMN:: Maybe we should be saying how to use stylesheets

WAC:: seems technique

DD:: Hakon/Bert probably have guidelines on how to use stylesheets effectively - they are the CSS experts

JW:: Part of it requires that new tech degrades gracefully - appropriate markup must be used - disallows P.h3 as a substitue for H3

WAC:: Does there need to be something in the Guidelines document - perhaps a checkpoint?

DD:: Maybe - don't have document in mind

*ACTION Daniel to follow up with Bert/Hakon

Server Guidelines - browser sniffing, Content negotiation, etc

HHTP language negotioation

JW:: Irreelvant what proportion of people have control over HTTP. If there are important principles they should be in the document. Mention HTTP, Language/content negotiation in checkpoints. Check with I18N

DD:: different guidelines? Different document?

JW:: Could probably be included in document

WAC:: relates to media types

CMN:: some of it is techniques rather than checkpoint

JW:: Yes - small changes to document

DD:: Browser sniffing is about server configuration choosing what the agent is - not necessarily harmful, but not especially good design. We should not forbid it. They generate the HTML based on guesses about teh user - the abuse is where the guesses are wrong or when the users are excluded.

Content negotiation: One part effects content - an HREF at W3C does not have extension on it - /Icons/w3c does not say anything about type. The server passes whatever Icons there are there based on accept-formats of client, so can serve png, gif, whatever based on client requests

It cannot be assumed that the author knows what the system is doing. So we could cause a problem.

*ACTION Charles check with Henrik about this (content negotiation).

WAC:: You could adjust A14 to talk about content negotiation

DD:: It is less than that at w3c

WAC:: It is a technique?

DD:: Additional

CMN:: Browser sniffing can be a worry - the assumptions can be wrong

DD:: This is more relevant to Authoring Tools

CMN:: Server stuff is covered in Authoring Tools in scope, although not adressed yet

JW:: Language negotiation should be covered in these guidelines

DD:: Agree. Should rely on language negotiation happening at HTTP level. Conditional on server control/support. Protocol does not provide list for available languages...

JW:: Should be integrated into language checkpoint. Further discussion into techniques. Also, content negotiation are spread across Authoring Tools, I18N, etc

WAC:: So author must mark up docs correctly, work with server to ensure serving is done properly

JW:: Some servers (eg Apache) allow users to write a directory-based control set.

WAC:: We should also mention media types. That could be sprinkled into the document.

DD:: Same exercise

CMN:: Is there an example in a browser

DD:: Yes

WAC:: It is very clear where language negotiation goes. Where does the media type go? Do we need to have a checkpoint? It's not as findable

CMN:: It is not as crucial to be findable

WAC:: A14 c4 - qpecify type for non-w3c technologies

CMN:: could be added as a technique

JW:: Could be added to the guideline itself

WAC:: I can work on something like that.

DD:: Yeah, cool

* WAC to add to checkpoint on language,

* JW to write something on TYPE for A14c4


JW:: any follow up to my question - should we prescribe one?

DD:: there are a number of ASCII schemes

Using a math graphic requires an ALT. When MathML will work, there will still be UAs which cannot parse it. Similar problem to frames

CMN:: I have a pet example of using OBJECT to include Math in several flavours...

JW:: Should we recommend particular solutions? What is the most accessible ascii representation of maths

CMN:: saying it in words. But it is not very easy for people to follow.

JW:: It is very verbose - wouldn't be fun.

WAC:: Do we need a specific checkpoint, or is it covered in A14

JW:: it is not graphic information

CMN:: I think it should be in techniques.

JW:: Should mention MathML where it discusses W3C technologies

WAC:: In intro to section A?

DD:: Would like specific mention of MathML in next release.

WAC:: So long as we add the name into the guidelines a bit and put techniques in, we have enough.


JW:: Trying to find place to link from guidelines

WAC:: A1 checkpoint?

JW:: That could be good

CMN:: Wendy could include it in rationale for A14

*WAC to sprinkle mention of MathML thoughout guidelines where applicable, but especially in A14. Also, to include link to math in graphics from A.1.1, make sure link to MathML from references, and that there is a discussion of proposed techniques in the techniques document.


>From issues list

CMN:: This was pre-checkpoints terminology. Conformance is based on compliance with guidelines. Checkpoints provide specific tests

JW:: We ahd a long dicussion on this - checkpoints, where relevant, must be implemented. But what is the set of checkpoints we reuire?

DD:: This is probably a cross-guideline issue. Ian and Judy are working hard on UA for that. Would rather wait for them.

WAC:: Haven't watched it as closely, but there was a recent proposal based on profiling.

CMN:: That is still under discussion. Should we ask CG?

WAC:: Agreed. Move on?

JW:: Need not be dfined identically in all three guidelines. Expressing caution of any recommendation for only requiring priority one checkpoints - it is impossible/possible, provides a minimal definition of accessible

CMN:: The priority specifications make it clear that only meeting P! only provides bare accessibility, P2 provides substantial access, P3 provides good access

* Conformance issue goes to CG

Changing priority of checkpoints.

A.5.2 - use sufficient contrast for people to use.

DD:: This is only relevant to people who can't change colours - don't know of any User Agent that doesn't allow this to be overridden.

WAC:: Backgrounds, text. Does not happen in Images.

DD:: Have guideline to provide content for images - longdesc

JW:: Are there circumstance in which user can't override colours?

CMN:: The 'absolutely essential' requirement has been met.

JW:: Would like to see original content made accessible

CMN:: Reducing to P2 gives us stronger grounds to demand real accessibility not bare minimum.

WAC:: Should we have a P1 somewhere?

CMN:: User agent problem

WAC:: There was a problem with the Guidelines - someone couldn't solve it

JW:: That's a problem for the user. Is there any case where it can't be overridden?

WAC:: There are times when SIZE can't be covered. Is the same for COLOUR

*WAC check to ensure that there is no problem in any browser that would prevent person from overriding poor color contrast. If none, move A.5.2 from P1 to P2.

A.10.1 - provide control over autorefresh rate.

CMN:: This is our P1 checkpoint for Cognitive disabilities

JW:: We have a conditional P1

CMN:: The condition can be used to reduce the strength against a 'my target market is NS 3 users...'

HFN (asked) Refresh is not HTTP

CMN:: Keep as P1, remove the Condition

WAC:: serves as a reminder that we should review it

JW:: Could we rephrase it to cover Charles' problem?

Should we add a note to point out that this is non-standard? (perhaps in techniques)

DD:: What is happening? Are you missing data

CMN:: You are missing data.

General discussion - examples given.

JW:: The instant redirection is a different case. The rest are legitiamte concerns

DD:: Can we have a technique that explains it in greaet detail.

*CMN to write a technique for A.10.1.

+resolved keep as P1

A.10.2 Avoid flicker

WAC:: P1 for people with photosensitive epilepsy. Have received new information about how to define it more clearly, but think it needs to be P1

JW:: Agree

DD:: This can be covered by non-standard HTML provision

WAC:: This can also apply to Anigifs, applets, etc

DD:: Playing Devil's advocate. Anything that moves is going to be a problem

WAC:: Is within a certain rate with certain features - we can define it reasonably specifically.

DD:: It is bad design too

CMN:: But people are going to design badly

DD:: Keep as P1

*WAC incorporate best information available to A.10.2.

A.9.2 ensure source of frame is markup.

JW:: Reason is becuase frame longdesc should provide explanation of frame, not its content. Only way to include alternative content for eg an image

CMN:: It is possible to make the information available by context, so support reducing priority

JW:: If content is variable then there needs to be alternative content provided within the frame

DD:: Agree, but there are ways to get to it other ways - DOM+script...

JW:: P1 prohibition on relying on script excludes that as complete strategy. Propose modification to make it clear that it only applies where the content of the frame is variable.

DD:: Explain what Jason said about longdesc being reserved - if the content is going to be changed use markup.

JW:: Is that clear?

WAC:: Yes.

JW:: Frames are very HTML specific

WAC:: We could apply it to a general container.

GV Joins

CMN:: There are lots of possibilities for containers whose content changes

GV:: If we generalise this we might get a deepr truth

WAC:: eg For a container whose content is vriable ensure that alternative information is available. That is P1, but seems redundant??

JW:: Expand the existing checkpoint

DD:: Don't see a big difference between a frame link with longdesc and an image link with longdesc - just that an Image can change through some other markup. In HREF image could be chagned by server side action. If you update the frame content and not the longdesc content you are violating A1. Say 'provide description of Frame content'

CMN:: I'd like to take what Wendy said as the checkpoint and put the rest into Techniques. The descriptive stuff can be provided by context

WAC:: Yeah...

DD:: Sounds OK

JW:: Make it clear that descriptions must be updated for updated content - applies to audio.

CMN:: Support Daniel - some of this is already covered in Guidelines.

* WAC modify A.9.2 checkpoint to reflect more general idea, move HTML specifics to techniques document.

A.1.6 replace ASCII art with Image and ALT text

WAC:: variable priority

DD:: If I provide a description somehow, is it OK

CMN:: Checkpoint is written too specific in the technique it outlines.

WAC:: We should say something like provide Alternative text in some form

GV:: It should be replaced by Image and ALT text. What other solutions are there?

JW:: D-Link

GV:: Don't want to leave content in document - causes problems

CMN:: Can be included by OBJECT

WAC:: Can use a 'skip-link'

GV:: Screen reader won't cope with OBJECT solution

DD:: There are cases where you point to ASCII art. These are fine right?

GV:: Yeah, fine

CMN:: Skip-link?

GV:: You could. Should it say 'use image+alt or link to it?'

CMN:: No, should say 'ensure ASCII art is not part of the inline text, and that it is described'

GV, JW Disagree

JW:: Charles is confused about techniques/guidelines/checkpoints and what goes where.

CMN:: Oh. Yeah. I am

GV:: ASCII art should either be replaced with Image, Alt, longdesc, OR a description and mechanism to avoid it.

*WAC - update checkpoint to read: ASCII art should either be replaced with Image, Alt, longdesc, OR a description and mechanism to avoid it. maintain priority 1.