Re: Is Java Web Start covered by WCAG?

Thank you, James.

Gregg, if it is unknown if Java Web Start may or may not pull stuff
using http (as James indicates below) and the the user (or evaluator)
has no way of knowing what the internal protocols are, then is it
correct to conclude that WCAG does not cover it?

Kindest regards,
Laura

On 4/28/17, James Nurthen <james.nurthen@oracle.com> wrote:
> The application launched using java web start may or may not pull stuff
> using http. That is unknown and to be honest the user (or evaluator) has no
> way of knowing what the internal protocols are.
>
>> On Apr 28, 2017, at 06:55, John Foliot <john.foliot@deque.com> wrote:
>>
>> David wrote:
>>
>> > I know it's messy, but until we widen WCAG content definition to all
>> > delivery mechanisms, and that won't be any time soon, I think WCAG is
>> > limited to that.
>>
>> I think I have to push back on this: using a delivery protocol to define a
>> "web page" is one thing, but this group has already taken on more than
>> that.
>>
>> The Mobile Accessibility Task Force proposals cover both "web" content,
>> "web apps" and Native apps, and in many cases those web apps and native
>> apps may not be using http (or, for that matter, any network protocol: see
>> Offline Web Applications - https://www.w3.org/TR/offline-webapps/)
>>
>> From the now dormant Mobile Accessibility WCAG Extension:
>>
>> The Mobile Accessibility Extension to WCAG 2.0 provides guidance to
>> improve accessibility for people with disabilities. While it generally
>> applies to traditional mobile devices, it also applies to touch-enabled
>> desktop devices, kiosks, tablets and other platforms that use technology
>> beyond the traditional mouse and keyboard. While it is primarily oriented
>> toward web and hybrid content, the guidelines and success criteria may
>> also apply to native mobile applications.
>>
>> Additionally, WCAG 2.0 today has 36 Techniques for Flash accessibility, 35
>> techniques for Silverlight, and 23 Techniques for PDF - and none of those
>> file formats are "web pages delivered via http" - yes, those file formats
>> *CAN* be embedded or linked to pages using http, but they themselves are
>> not "web pages", they are "content".
>>
>> Internally at the W3C, other Working Groups / Interest Groups are now
>> referencing WCAG as well, for content that again may or may not be
>> delivered via http - for example, look at the activity happening at the
>> Digital Publishing Interest Group:
>>
>> Digital Publishing is a generic term for the broad ecosystem of electronic
>> journals, magazines, news, or book publishing (authors, creators,
>> publishers, news organizations, booksellers, accessibility and
>> internationalization specialists, etc.). Formats used by eBook readers and
>> tablets for electronic books, magazines, journals, and educational
>> resources are W3C Technology-based. (X)HTML, CSS, SVG, SMIL, MathML, and
>> various Web APIs are all part of modern digital publishing workflows.
>>
>> I also note with a wry smile that currently the WCAG 2.0 Rec is served
>> from the W3C server via https, and a strict LEGAL reading and
>> interpretation of WCAG, using only the transport protocol as the defining
>> 'break point', could (technically) exclude WCAG itself from meeting it's
>> own standard. (FWIW, I sort of like the dpub's bright-line as
>> "W3C-Technology based", and I would suggest that this phrase may be more
>> suitable going forward.)
>>
>>
>> Chairs, at least 3 active members of this Working Group have now suggested
>> that we need more clarity here (Mark Hakkinen, Jon Avila, myself), and so
>> this is a Formal Request to add this topic/discussion to an upcoming
>> teleconference agenda. It is my personal opinion that the current WCAG
>> definition for "Content" suffices for our greater needs, but I personally
>> reject using *only* the delivery protocol (in 2017) as the delineator
>> between what content *is* covered versus what *isn't*.
>>
>> JF
>>
>>> On Fri, Apr 28, 2017 at 7:30 AM, Laura Carlson
>>> <laura.lee.carlson@gmail.com> wrote:
>>> Hi James,
>>>
>>> Can you please answer which of the following (per Gregg's message
>>> below) is true?
>>>
>>> 1. Java Web Start does not pull content from the web using http:
>>> or
>>> 2. Java Web Start does draw content from the web using http:
>>>
>>> Thank you.
>>>
>>> Kindest Regards,
>>> Laura
>>>
>>> On 4/28/17, Gregg C Vanderheiden <greggvan@umd.edu> wrote:
>>> > if the java app does not pull content from the web using http:  — then
>>> > I
>>> > would agree that it is not covered.
>>> >
>>> > If the java app (or any app)  DOES draw content from the web using
>>> > http:// —
>>> > then it would be a user agent.  It would be covered by user agent
>>> > guidelines
>>> > — and its content (that it pulls using http://)  would be web content.
>>>
>>> --
>>> Laura L. Carlson
>>>
>>
>>
>>
>> --
>> John Foliot
>> Principal Accessibility Strategist
>> Deque Systems Inc.
>> john.foliot@deque.com
>>
>> Advancing the mission of digital accessibility and inclusion
>


-- 
Laura L. Carlson

Received on Friday, 28 April 2017 15:00:53 UTC