Re: Is Java Web Start covered by WCAG?

Jason wrote:

> *This is a good point. If the video is embedded in an HTML-based Web
page, then whether the Web page conforms or not presumably depends on
whether or not the video conforms, so it’s covered. However, if (assuming
this is possible) it’s linked to rather than embedded, then it’s more of a
separate resource and questions arise.*

Video formats can be delivered over the network using a number of different
protocols, including both streaming protocols (see here:
http://www.streamingmedia.com/Articles/Editorial/What-Is-.../What-Is-a-Streaming-Media-Protocol-84496.aspx)
as well as more 'packet' based protocols (http, ftp, gopher <smile>,
whatever). However, with the second category of protocols, you need to
download the entire file to the local host before the video will play
properly, which often causes serious buffering issues. Streaming protocols
(and as I recall there is even a pseudo streaming hack) do not wait for all
of the packets to arrive before rendering on screen.

HTML5's <video> element supports either streaming or packet-based protocols
however, and so in some ways I'd argue that either would be "in scope"
especially when we start to discuss packaging the required accessibility
support files in-band of the video wrapper; so for example your .mp4 file
might have an H.264 encoded video, AAC encoded audio description files, and
WebVTT text (caption) files all wrapped up inside of the .mp4 file.

If you crafted such a file, and then linked it from a web page *<a
href="http://video.mp4 <http://video.mp4>>See the video</a>* all of the
support content (mandated by WCAG today) would be included in the .mp4 file
(even thought that file is not a "web page") and *I* would report that link
and file as being "compliant" to WCAG.

If I linked the same file like this instead: *<a href="rtsp://video.mp4>See
the video</a>* as an evaluator I'd still expect to find the captions,
described audio/video description file, and perhaps even the transcript
made available to the end user before i could report compliance. *HOW* you
do that I'm less concerned with, only that you *DO* do so.

All which further suggests to me that the http protocol as an identifier of
"content" (or even "Web Content") is a red herring.

JF

On Fri, Apr 28, 2017 at 12:38 PM, White, Jason J <jjwhite@ets.org> wrote:

>
>
>
>
> *From:* Alastair Campbell [mailto:acampbell@nomensa.com]
> *Sent:* Friday, April 28, 2017 1:30 PM
>
> Well, most connections are now over httpS, and behind the scenes that is
> becoming http2, so it doesn't work from that point of view.
>
> *[Jason] I agree, and it obviously depends on whether you treat HTTP as
> including all of the variants (whether TLS is used or not, whether it’s
> HTTP 1.1 or HTTP 2, etc.).*
>
>
>
> I'm less certain of this but i believe that a lot of video is delivered by
> UDP or RTSP, have you checked to see if a particular video is covered by
> WCAG based on the protocol it uses?
>
>
>
> *[Jason] This is a good point. If the video is embedded in an HTML-based
> Web page, then whether the Web page conforms or not presumably depends on
> whether or not the video conforms, so it’s covered. However, if (assuming
> this is possible) it’s linked to rather than embedded, then it’s more of a
> separate resource and questions arise.*
>
> > If we want to widen it for future versions that is another matter... but
> as far as clarity, the definition of web page is very clear in the
> standard. It says exactly what the working group  intended it to say.
>
>
>
> And there are plenty of people who can't work out what that means anymore..
>
> *[Jason] I agree there are issues; I agree the definition should be
> widened (we have an open issue on that question).*
>
>
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> ------------------------------
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion