Re: Issue summary for Guideline 1.2

I probably owe Wendy and Tom Croucher some more material on these topics, 
but every time they ask I have a hard time adding more to what I've 
already given them. Except for rererecorrecting the same errors, of 
course.

And keep in mind that you don't have a plausible justification for *three* 
levels of conformance, so every passage that says "We only require this in 
Level 3" needs to be understood as "We'll only require this in Level 2." 
There won't *be* three success levels because you don't *have* enough 
content for them and never will; studies show that no real-world sites 
comply with Level AAA; and it has been reasonably argued that such 
compliance is actually impossible. However, Gregg sure likes the idea, 
which is usually enough for the rest of you.

> Changes to 19 November 2004 WD should address; Reviewer verification required
[...]
>   In previous drafts, there was an exception for content that was
>   rebroadcast. However, it was worded in such a way that readers
>   interpreted it to mean that if content was rebroadcast it was exempt
>   from captions, i.e., it did not need to have captions to be
>   accessible.

I don't know how they could have read it that way.

>   19 November 2004 text: If multimedia content is rebroadcast from
>   another medium, the accessibility features required by policy for that
>   medium are intact.

As I've explained before, though, if a broadcaster has a captioning 
requirement of X%, where X<100, then they could post content only from the 
Y% that isn't captioned and legitimately claim they were meeting the 
guidelines. To adapt an actual example from Canadian TV, a licensee of a 
British network whose captioned shows are only old Canadian reruns could 
post British shows on its Web site and note that, since they meet their 
captioning requirement through their Canadian shows, the British shows 
don't have to have captions *anywhere*.

Or a site could post content that appears on TV during times of the day 
when captioning isn't required, e.g., after 0100 hours (Canada, usually) 
and outside 1830 to 2230 hours (Australia, usually).

Or a site could post uncaptioned content that appears with captions on TV 
but which is deemed to be *in excess* of the TV requirement.


>     * Concern about the term "video-only" since most Web pages are
>       "video only presentations."

Static Web pages are not video.

>  [8]Issue 793 - Clarify the Level 2 success criteria (pending)
[...]
>   In the [9]11 March 2004 WD, the following multi-part exception applies
>   to the level 1 criteria for captioning and audio description: "if the
>   content is real-time and the content is audio-only and the content is
>   not time-sensitive and the content is not interactive, then a text
>   transcript or other non-audio equivalent does not need to be
>   synchronized with the multimedia content."

"Real-time captions aren't required for live audio Webcasts." Simpler, nu?

The only realistic way to provide real-time captions in that case is to 
pop up *some kind* of video frame, if only an iframe with scrolling or 
crawling text manipulated via DOM.

>   "There are questions about what is possible and what should be
>   required for real-time audio description since there is no way to know
>   when there will be gaps in audio (when descriptions could be read) and
>   other issues with describing real-time events."

We should evaluate what kinds of video are actually presented live online. 
Is it all computer seminars and Webcams at Burning Man?

And also, it's possible to plan for likely pauses or other moments in 
which to describe. The U.S. presidential inaugurations are pretty clean, 
all things considering, and that's attributable to advance planning.


>  [10]Issue 980 - Making live broadcast/time-dependent content more accessible
>  (pending)
[...]
>   The reviewer's comment
>
>     ...For example, in
>     modern subtitling,

In real-time captioning used since the late 1980s, you mean.

> computer programs are used where the
>     stenographer simply has to press one button to print a particularly
>     common phrase, such as a description of a common pattern of play in
>     sports commentary.

It's almost never exactly "one button" and almost always a set of chorded 
keystrokes. The example given is rather poor.

> Such solutions should be encouraged in the Best
>     Practice of this guideline, without necessarily making them a
>     condition of conformance.

This doesn't make any sense at all and can be disregarded. Does the 
reviewer envisage a new system for live audio description with nice big 
(and probably backlit) buttons that spit out audio recordings of certain 
catchphrases? I guess we're remixing audio descriptions now.


>  [11]Issue 1028 - Collated text transcripts, realtime captioning, and
>  describing (pending)

I told Wendy and others at the Toronto f2f that there is no evidence at 
all that "collated text transcripts" are even desired by the only group 
that has a rational need for them, deaf-blind persons. I suggested that 
organizations be surveyed to get some actual data. Everyone liked that 
idea, but nobody did anything about it.

Note that WGBH later worked on a project that produced some "collated text 
transcripts." No doubt one motivation was to disprove the previous claim 
that it had only been tried once before, which indeed it had-- by WGBH, in 
fact.

<http://joeclark.org/access/captioning/bpoc/WCAG.html#DigNubia>


>   Despite the cost and lack of support for these
>   techniques, we hope that in the future they are more readily
>   achievable.

So we should hope they're achievable even though we have no evidence 
people actually want them?

>  [12]Issue 952 - Ease of access
>
>     [12] [23]http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=952
>
>   The reviewer writes, "An audio script is recommended here and <em>ease
>   of access</em> to this script should be stressed."

What's an "audio script"?

>   For Guideline 1.1, we said "ease of access" is a user agent issue.
>   However, since there is not always a means to programmatically
>   associate a transcript with an audio clip, this can not be left solely
>   to the user agent.

We'd need some HTML examples. Even using the <object> element, assuming 
you can get it to work in IE/Win, makes it possible. And the existing 
practice is to simply link to the transcript. What's the problem?

> It seems to depend on the definition of "explicitly
>   associated" that we are waiting for from the [13]13 January 2004
>   telecon. It could be a combination of user agent and markup language
>   issue. Perhaps a repair technique in the meantime? Research needed.

<a rel="alternate transcript"></a>, for example.

<http://www.w3.org/TR/REC-html40/types.html#type-links>

>   There is a Note in the 24 June 2003 WD that says, "the presentation
>   does not require the user to read captions and the visual presentation
>   simultaneously in order to understand the content."

This is another example of the Working Group's fondness for Kafkaesque 
conundrums like permitting X as long as the exact opposite anti-X is 
provided that does precisely the same thing. If anti-X worked, we'd use it 
in the first place by itself and wouldn't need X.

If we didn't need to watch video and captions simultaneously, we'd read 
separate transcripts. Ah, but that really *is* the agenda of the academics 
of the Working Group. Anything backward and inconvenient is preferred.


>   The reviewer says:
>
>     This point should be a Required Success Criteria. Captions that
>     need to be read at the same time as watching action on the screen
>     do not provide an equivalent user experience.
>
>   However, another reviewer (comments not available online)

Comments indeed available online and cited previously:
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1028>

> says that
>   this is what watching captions are all about and therefore the Note
>   should be dropped.
>
>   Propose that something is said in the General Techniques or
>   multimedia-specific techniques.

Propose that the Note should be dropped.


>  [15]Issue 983 - Holes in media-equiv

>   Further, the reviewer says:
>
>     1. Where subtitles are displayed, the designer should ensure
>     sufficient contrast between foreground text and the background
>     behind it (ideally, the user should be given the option to display
>     a caption box behind the subtitles which has a colour that
>     sufficiently contrasts the colour of the text).

Yeah. How are you gonna do that? And they're captions, not subtitles.

>     2. A minimum size and recommended font for subtitles should be
>     provided (the Royal National Institute of the Blind recommends a
>     minimum of 16 point Helvetica or Arial font).

I assume that blind people *would* recommend a hideous parody of the 
grotesk form like Arial, yes.

>     3. A minimum audio quality requirement should be specified for all
>     audio description.

Really? Then audio description on SAP on NTSC television would flunk. Yet 
is it manifestly sufficient.

>     4. If a sign language interpreter is to be displayed on-screen,
[...]
>   There is concern by another reviewer that requiring sign language
>   starts us down the slippery slope of requiring translations to every
>   language and that "sign languages are by definition not "in the
>   language of the dialog[ue]." There is no dialogue in sign language."

I'm the one who said that (repeatedly) and I say it again.

>   Propose close the issue and include the Best Practice suggestions in
>   General Techniques (i.e., close this issue for WCAG 2.0 and open an
>   issue for General techniques).

Please explain in plain English what you are really proposing.

> Elephants

"Elephants"?

>     How should we address presentations that contain only audio or only
>     video

Silent video is pretty rare.

> and require users to respond interactively at specific times
>     during the presentation? Since it is not multimedia,

Audio isn't multimedia?

Video isn't multimedia if it doesn't contain sound?

>            he/she wants). In fact, accessibility for Flash could be more
>            closely related to issues of television broadcast
>            accessibility, except that Flash is interactive, and
>            televisions are not."

Flash *can* be interactive. Usually it's just a really sexy animated GIF 
in this context.

>          + "Just because someone accesses your equivalent alternative,
>            doesn't mean that they are blind and don't care about what
>            the page looks like or how it functions."

That's rather interesting!

>            "Providing captions in Flash offers accessibility to users
>            who cannot hear or fully understand audio content. Because of
>            the interactive nature of Flash, captions can be turned on or
>            off and can be programmed to display in many ways."

And they're nearly always tiny, blocky (only Flash 8 will have 
anti-aliasing, I am told), set in too-long lines, and borderline 
impossible to read.

>          + Using sound within Flash - Guideline 1.4, Level 2 #3: Users
>            can disable background audio that plays automatically on a
>            page so that it does not interfere with text reading software
>            they may be using. - should this be level 1?

Heavens, yes! You get this a lot at band sites, which are already pretty 
bad.

<http://www.43folders.com/2004/12/five_mistakes_b.html>

> Will it be a
>            user agent feature in the future? Seems to be covered by
>            [28]UAAG 1.0 Checkpoint 3.2 Toggle audio, video, animated
>            images (priority 1).

Good idea to push that one a bit more. *Lots* of people would love to be 
able to tick a box and never be surprised to hear sound coming out of 
their computers again.

>  [29]Issue 1151 - Scoping requirements, relation to policy
>
>   Reviewer suggests that we will need scoping requirements for the
>   following: ...
>     * multimedia that is posted as an example or counterexample of
>       accessible content (including learning examples)

That's a persistent problem in our guidelines. We can't teach people to 
make accessible pages if we can never post inaccessible content for them 
to work on.

>     Propose that WCAG 2.0 not attempt to create a phase-in schedule.
>     Instead, we look at a scoping mechanism that would allow developers
>     to exclude multimedia that hasn't been captioned or described and
>     leave phase-in schedules to policy makers.

This doesn't make any sense at all and nobody has come up with a more 
credible option than my original one, which is to permit phase-ins.

-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
       --This.
       --What's wrong with top-posting?

Received on Wednesday, 19 January 2005 18:15:30 UTC