Re: Is Java Web Start covered by WCAG?

Related to this discussion: https://www.w3.org/TR/pwp-ucr/

While it is useful to have a definition of "web page", I think that we
should be more closely focused on Content (also defined) rather than
"format" and "delivery mechanism".

JF

On Mon, May 1, 2017 at 2:22 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> Chiming in here just to say that I did see John’s request for this to be
> discussed by the group, and I agree that we should, but it won’t be on the
> agenda for a few weeks.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe
>
> akirkpat@adobe.com
> http://twitter.com/awkawk
>
> From: Mike Elledge <melledge@yahoo.com>
> Date: Saturday, April 29, 2017 at 16:32
> To: David MacDonald <david100@sympatico.ca>
> Cc: Gregg Vanderheiden <greggvan@umd.edu>, John Foliot <
> john.foliot@deque.com>, Jason J White <jjwhite@ets.org>, Alastair
> Campbell <acampbell@nomensa.com>, WCAG <w3c-wai-gl@w3.org>
> Subject: Re: Is Java Web Start covered by WCAG?
> Resent-From: WCAG <w3c-wai-gl@w3.org>
> Resent-Date: Saturday, April 29, 2017 at 16:32
>
> 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
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7C%7C8cf42dfa940b46edd10608d48f3f0c4e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636290948365934502&sdata=hwwXrEtuWZgQZg8NVatGDUW7tUPpRvP0EuLNqChiJcI%3D&reserved=0>
>
> twitter.com/davidmacd
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7C%7C8cf42dfa940b46edd10608d48f3f0c4e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636290948365934502&sdata=YooC%2Bln8pThmoX%2FfJNMJ1tUOgCTJCyE099Cekgdgg4k%3D&reserved=0>
>
> GitHub
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7C%7C8cf42dfa940b46edd10608d48f3f0c4e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636290948365934502&sdata=HlFDiiOsOO3yIiH3lysjPg69Wa%2Fkk3j%2FN2dpm9UGdW4%3D&reserved=0>
>
> www.Can-Adapt.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7C%7C8cf42dfa940b46edd10608d48f3f0c4e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636290948365934502&sdata=LZrOQ8SJ%2FY01ThyDOofAnU10RAQ%2BF2hQK4LjYJxsQbI%3D&reserved=0>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7C%7C8cf42dfa940b46edd10608d48f3f0c4e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636290948365934502&sdata=NA8JNchGVG3rYDIPkOWFOPLb8qsrPqgYPY0bkzePdEU%3D&reserved=0>
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG20%2F%23useragentdef&data=02%7C01%7C%7C8cf42dfa940b46edd10608d48f3f0c4e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636290948365934502&sdata=CMzZ58ls44Xd0anUkaXd6r17D%2FKxliC4AKfi%2BorZPis%3D&reserved=0>
>>
>>
>> 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
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.streamingmedia.com%2FArticles%2FEditorial%2FWhat-Is-...%2FWhat-Is-a-Streaming-Media-Protocol-84496.aspx&data=02%7C01%7C%7C8cf42dfa940b46edd10608d48f3f0c4e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636290948365934502&sdata=aWNi2JhCssvjj5VjYV0Wz8WZnlDMtkcnOjlKakQXmyQ%3D&reserved=0>)
>> 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
>>
>>
>>
>


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

Advancing the mission of digital accessibility and inclusion