Re: Is Java Web Start covered by WCAG?

Hi All--

This is an interesting discussion and a valuable (necessary) opportunity to define WCAG's scope. I hope we don't lose sight, however, of our overriding intention: ensuring that online content is accessible to everyone (to the greatest extant possible). To John's (?) point, including Silverlight, Flash and PDFs in techniques and describing WCAG as technology-agnostic broadened WCAG's applicability--and utility--in a good way. It is important to me as an advocate and evaluator to be able to apply both the letter and the spirit of WGAC  to content delivered to users, without worrying about someone saying "Yes, but..." because of a technical definition. 

So, yes, let's debate, define and if necessary revise WCAG's scope, but not to the detriment of the audience we're committed to helping.

Mike

> On Apr 29, 2017, at 9:49 AM, David MacDonald <david100@sympatico.ca> wrote:
> 
> +1
> 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn 
> twitter.com/davidmacd
> GitHub
> 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
> 
>> 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
>> 
>> 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>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
>> 
>