- From: David MacDonald <david100@sympatico.ca>
- Date: Sat, 29 Apr 2017 09:49:13 -0400
- 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>
- Message-ID: <CAAdDpDZa4yhhFpVs=B7GkPPMJrtqV6C1jcoyW=vHPBJe3R-r8A@mail.gmail.com>
+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