Thursday, 11 January 1999 4:00 - 5:30 PM EST
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
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.
+resolution?
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
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.
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
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.
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.
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.