Re: About WAI Accessibility Guidelines

> The first section (A) is about "Graceful transformations."  A
> transformation is not necessarily a textual representation of a graphical
> or auditory element.  It could be a still image of a frame from a movie, or
> auditory descriptions of the visual presentations within a movie.  So, our
> definition of transform gracefully is, "a page remains usable despite user,
> technological, or situational constraints."  Therefore, A.6, A.7, A.9, and
> A.12 are definately guidelines for graceful transformation.

I still disagree, but I guess we're down to expert/religious opinion,
so I'll give (just tell me why A.6 is in A and B.2 in B, rather than
both in B)

> again, A.14 (text-only page) is the last ditch way to make a page
> transform gracefully. so we believe it should stay where it is in A.

I view it as the last ditch to make a page *accessible*, so I'll put
it at the end of the guidelines. 
 
> The recommendation will be just the linearized version of the guidelines
> (to be posted after this is sent).  The techniques will be a separate
> non-normative document.  However, links to the techniques document will
> appear throughout the guidelines - as they appear now.  (The "leading"
> techniques are the items in the techniques column?)

That's the way we should do it, but we need to be very careful that
the normative part holds together as a unit.
 
> image:  a graphical element presenting information visually

We need to add in the notion of "still" I think, vs. moving/video
which come later.

> applets: applications that can not stand alone (i.e., a sub-process that
> runs within a user agent process space). 

There is no such thing as an application that can stand alone: they
all stand on a lower layer (down to the silicium), and in the case of
an applet, the lower layer is just an interpreter embedded in a
browser.

I thing a better characterization for applets is the notion of "mobile
code", that is, programming code (by opposition to declarative markup)
that is downloaded in a user agent and run in this context.

> >Instead of "have chosen not to" I'd say "cannot view graphics"
> >otherwise people might react "Oh, you don't *want* to see my
> >graphics, then get lost".
> >
> how about "or any users who have chosen not to view graphics."  Some people
> choose not to view graphics either because they can not due to a physical
> disability, or they have chosen not to because it would take too long to
> download.  

If I'm using a mobile browser, I just *cannot* view graphics: my
browser doesn't fetch them and show them. You might argue that I chose
to use this image-less mobile browser, but maybe not, maybe that's
what my company had bought for me.

So where is my case in your list ? I am not blind, doesn't have low
vision, and I have not chosen not to view graphics.

How about we have both "or any users who cannot or have chosen not to
view graphics" ?

> >We should have a lead to spacer images, bullets and difference between
> >pure decoration and functional images at that point, with pointer to
> >more detailed techniques.
> >
> we think it best to leave the link as is, and provide the detail in the
> techniques document.

Sure, the details should be in the techniques, but the way it is now,
it's hard to find the list bullet alt and the space alt
details. Wherever the direct links to these techniques are (please
tell me), it seems obvious to me that they should also be here
(redundancy helps, there is already some for imagemap I think).

> since this sentence appears in the guidelines (which will be normative) and
> we aren't sure what all is possible or needed, we were purposefully vague
> with this one.

We cannot be that vague in a Recommendation. If you take Technique 1
in this list "For all images (IMG) provide alt-text", this is not
vague, this is very precise, and the techniques document answers the
next series of questions about what goes inside alt-text. 

I think we should mention that "For OBJECT, specify alt-text either
with the "title" attribute or in the body of the OBJECT element", and
point to the techniques.

> However, if it's Beethoven's 9th, will I provide the score?
> No, but the caption "Beethoven's 9th played by the Chicago Symphony
> Orchestra" should be sufficient.  Therefore, all audio gets captioned.

How about all the words of the "Ode to Joy" ? (last movement, which is
also the European Anthem - see http://europa.eu.int/en/eu/anthem.html)
These are important to caption!

To me, "Beethoven's 9th played by the Chicago Symphony Orchestra" is
not a caption, it's a title.

So here, we have an interesting case: I'd argue that if what you're
putting online is the 9th, then a descriptive title is enough, not
need for attaching all the lyrics, but if what you're talking about in
your page is Anthems, then you need to provide transcript for this
part, because that's an important aspect of the information.

Same things goes for regular songs or audio. Only the author can judge 
what is important or not.

> Well, it could fit into "separate structure from presentation" but we
> thought it would be easier for an author to understand and find if we
> grouped the two color techniques into one color guideline.  

It's not that it could fit into "separate structure from
presentation", it's exactly what it is, and setting it aside just adds
to number of guidelines, which is bad.
 
> tee-hee.  if we change Hertz to "flashes per second" does it still make you
> want to dig out the analyser from the basement?  We can't provide a good
> way to determine the high end (the low end is fairly simple), but know it
> is an established set of limits.  any ideas?    

More to the point, as an author, what control do I have over the
frequency of moving element on the user agent side ? probably close to 
none.

So I would just say "Avoid any blinking or updating of the screen that
causes flicker" and mention the Hertz thing in the technique documents.
 
> The rationale
> is, "Some pages will be unable to transform gracefully at this time either
> because the visual components are too complex, or because assistive
> technologies or user agents (browsers) are lacking a specific feature.  For
> example a complex table (e.g., of text and numbers) must be converted into
> a linear version."

Good

> yes, it is a UA issue and luckily a couple UAs have made some headway on
> this (lynx and Jaws).  So, we are moving this to A.12 - "Use interim
> accessibility solutions so that assistive technologies and older browsers
> will operate correctly" and making it a Priority 2.

OK, can you remind me what it means to have a P1 Technique for a P2
Guideline ?
 
 

You're right in theory for the priority on Bobby, HTML validation,
etc, but in practice, if we keep them to P3, we're not encouraging
their use, and that's bad, because they really help catching a lot of
things.

So I would really prefer to extract them from the Guidelines set and
put them (the whole C.4) at the end, as an annex.

In fact, these are not guidelines about page content, but guidelines
about page validation (i.e. tool), so they ought to be set aside from
the rest.


Couple of new comments:

> A.2. Provide descriptions for graphics, scripts, or applets if they
>  are not fully described through alt-text or in the document's
>  content. [Priority 1]

I'd add ".. for important graphics"...

> A.7. Ensure that moving, blinking, scrolling, or auto-updating
> objects or pages may be paused or frozen. [Priority 1] 

As an author, what control do I have over the movement of animated
GIF?

None I think, it's done in the browser.

Do are we saying: no animated GIF ?

I think this is for A.12: interim stuff for old user agent.

Received on Tuesday, 8 September 1998 05:21:28 UTC