W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: Is Java Web Start covered by WCAG?

From: David MacDonald <david100@sympatico.ca>
Date: Sat, 29 Apr 2017 09:49:13 -0400
Message-ID: <CAAdDpDZa4yhhFpVs=B7GkPPMJrtqV6C1jcoyW=vHPBJe3R-r8A@mail.gmail.com>
To: Gregg C Vanderheiden <greggvan@umd.edu>
Cc: John Foliot <john.foliot@deque.com>, Jason J White <jjwhite@ets.org>, Alastair Campbell <acampbell@nomensa.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
+1

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Sat, Apr 29, 2017 at 2:44 AM, Gregg C Vanderheiden <greggvan@umd.edu>
wrote:

> note that a web page is
>
> a non-embedded resource obtained from a single URI using HTTP plus any
> other resources that are used in the rendering or intended to be rendered
> together with it by a user agent
> <https://www.w3.org/TR/WCAG20/#useragentdef>
>
>
> So it includes items fetched using other protocols that http://   IF they
> are intended to be rendered together (including pop ups etc) as part of a
> page.
>
> But not things that are just downloads.
>
>
>
>
> Gregg C Vanderheiden
> greggvan@umd.edu
>
>
>
> On Apr 29, 2017, at 2:31 AM, John Foliot <john.foliot@deque.com> wrote:
>
> 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
>
>
>
Received on Saturday, 29 April 2017 13:49:48 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:12 UTC