Re: Is Java Web Start covered by WCAG?

>Including Silverlight, Flash and PDFs in techniques and describing WCAG as
technology-agnostic broadened WCAG's applicability--and utility--in a good
way.

PDF is covered when it sits at a URI and is delivered via HTTP. Flash and
SIlverlight were included because they were " ... any other resources that
are used in the rendering or intended to be rendered together with it by a
user agent"

It was a ton of work to create and vet those techniques, but we did it
because they were considered a web page or part of a web page, and
therefore covered.


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 4:32 PM, Mike Elledge <melledge@yahoo.com> wrote:

> 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
> <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
>>
>>
>>
>