Re: Is Java Web Start covered by WCAG?

Laura wrote:

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

With no offense to Gregg, I think that is the question this Working Group
needs to re-visit.

Personally, I think it is correct to conclude that the delivery protocol in
the Java Web Start discussion is irrelevant, however, whether or not WCAG
covers content initiated via Java Web Start, but rendered using common user
agents, is still unknown (or at least undecided).

Some of us are now questioning the validity of using the http protocol as
the decider here, as it simply does not reflect what we see in the wild
today. I think this WG understands that there was a decision made 9+ years
ago, but I will suggest / request that we check our assumptions (and that
decision) going forward, and if possible, improve WCAG 2.1 in ways beyond
just adding more Success Criteria.


Alastair wrote:

> Web Page …the term "Web page" includes an immersive, interactive
movie-like experience found at a single URI and rendered in a standard user
agent.

Uhmmm... except when it's not. (I'd politely suggest that there is nothing
immersive or movie-like about the following "web page" -
http://info.cern.ch/hypertext/WWW/Protocols/RelevantProtocols.html)

That said, I think that Alistair is pointing us in a better direction with
his proposed edits, and so I'd like to keep banging on this a bit more
(please). And while I agree that defining "web page" is useful, given that
the "C" in WCAG stands for Content, I will continue to argue that "content"
trumps "web pages" when it comes to applicability, and that Alastair's
focus on "standard user agents" may be the better delinator here.

JF



On Fri, Apr 28, 2017 at 10:00 AM, Laura Carlson <laura.lee.carlson@gmail.com
> wrote:

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


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

Advancing the mission of digital accessibility and inclusion