RE: [media] progress on video transcript discussion

Silvia Pfeiffer wrote:
> >
> > I am thrilled to see it
> being
> > used more and more every day in mainstream development, but we must
> all
> > remember that it is designed for (and currently only works with) AT
> tools,
> > which only cover a small percentage of people with disabilities.
> 
> I am proposing ARIA as a solution where only people with disabilities
> need it.

But this is where your understanding of ARIA seems to break down. ARIA is
tha bomb, but only if you are using an ARIA aware tool, which currently is
Screen Readers and related vision assistance tools. It is not for "people
with disabilities", it is for primarily blind users, who are users with but
one type of disability.

Consider a tool like Read & Write Gold, which is an AT solution that assists
users who may, for example, be severely dyslexic: 

	"For those people who struggle with reading and writing due to
disabilities such as dyslexia; text to speech software is the perfect
solution. Read and Write Gold is an easy to use toolbar which sits
discreetly on top of any open Windows application. Users are given the
opportunity to work in an inclusive manner with their peers by offering
additional support when reading or composing text by providing
text-to-speech facilities throughout the software program; making it an
ideal solution for literacy difficulties, people who have dyslexia or for
those learning English as a second language."
(http://www.dyslexic.com/read-write-gold) 

[Read Write Gold also has a text highlighting feature, very similar to what
we see in "interactive transcripts" such as those from 3Play media, where as
the word is read aloud, it is also highlighted on the screen]

I will suggest that for those users that Read Write Gold has been created
and targeted to, access to a transcript will be a significant assistance (if
not outright requirement), yet linking the fact that a transcript exists by
only using an ARIA technique will fail these users completely.  Read Write
Gold is not a "web tool", and it was never designed to deal with content
that is targeted to some users but not others, which is essentially what all
of the current hiding techniques do in the current web language.  

I appreciate that you want to find a solution for those users who need a
transcript in the scenario where the designer does not want a visible <a
href>link</a> to display on-screen, but using ARIA alone is not the
solution, as much as you and others may want it to be.  It is for this exact
reason that I continue to insist that a mechanism for exposure and selection
needs to be closely linked to the primary media controls in some fashion. I
have already suggested that imposing "the 1 way" now is perhaps early, and
that a time for experimenting with various control solutions is appropriate,
but simply shunting it off to "ARIA: job done" is sadly not enough.



> Where everyone needs a solution (and there is indeed such a
> use case), I have proposed a different attribute - you might want to
> re-read my proposal (sorry it got so long, but reasons need to be
> explained).
> 
> Web developers in search of a solution for users with disabilities
> will turn to ARIA now - that's an achievement to celebrate and a
> trodden cowpath that works. I am just following it for the part of the
> transcript problem that relates only to users with disabilities.

To reiterate what I wrote earlier, I *DO* celebrate the progress that ARIA
has made, especially in the most recent 2 years, where support continues to
grow not only on web sites and within JavaScript libraries, but also in
ARIA-supporting tools. But ARIA is not the panacea for all accessibility
problems, and this point needs to be clearly articulated and understood by
all. ARIA augments effective solutions by ensuring that those solutions are
also transmitted to the Accessibility APIs for those tools that use those
APIs - nothing more (and nothing less). ARIA is not *THE* solution, it is
*A* solution for *some users*.

I do not know how else to better explain this, but fear that I am now
retracing old information.



> 
> As for the programmatic linkage that you are after: my proposal
> actually includes this with @transcript being a URL and not an IDREF
> any longer for the reasons explained.

This is actually what my first proposal sought to do - to create the linkage
to the transcript directly as an attribute that took the URL of the
transcript
(http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposal/Issue194). I
still believe that this could be an effective solution, but the overwhelming
feedback from many implementers was less than encouraging (and I am being
both gracious and charitable in that characterization). The WHAT WG IRC logs
will surface the actual response if you care to seek them out (however they
were *considerably less* charitable or gracious, and were in fact quite
personal in nature).



> Since it is now very clearly a
> link, it is indeed possible for developers to experiment with buttons
> or other interaction mechanisms on the video player if they want to.
> So, I think it meets the requirement that you're posing.

Yes, it does indeed.

JF

Received on Friday, 8 June 2012 06:40:23 UTC