W3C home > Mailing lists > Public > public-wcag2ict-tf@w3.org > July 2012

Re: Looking at SC 2.4.5 Multiple Ways with "UI Context"

From: Loïc Martínez Normand <loic@fi.upm.es>
Date: Mon, 16 Jul 2012 00:22:21 +0200
Message-ID: <CAJpUyz=S5VMHLazj9kUWUXBG0jdo4Hrbp991KtPAknkN3kyWbw@mail.gmail.com>
To: Peter Korn <peter.korn@oracle.com>
Cc: Gregg Vanderheiden <gv@trace.wisc.edu>, public-wcag2ict-tf@w3.org

(My reply at the end)

On Fri, Jul 13, 2012 at 3:56 AM, Peter Korn <peter.korn@oracle.com> wrote:

>  Gregg,
>   <PK>
> Hi gang,
> SC *2.4.5<https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/245-multiple-ways>
> ** Multiple Ways *was not one we reached consensus on.  Nor have we had
> much discussion on it thus far.
> My thoughts on that can be found at the Applying UI Context<https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/applying-ui-context>page in the fifth row, but to facilitate discussion, I reiterate them here.
> The software portion of the UIC Proposal is:
> For software this applies directly as written and as described in  INTENT
> from Understanding WCAG 2.0  (above) with the word “user interface context”
> substituted for Web Page  and "software program" substituted for "set of
> web pages".
> NOTE:  In the Understanding WCAG 2.0 writeup for this success criterion
> the WCAG Working Group gives examples of browsing and search as two
> possible methods for locating a Web page within a set of Web pages.  Both
> of these approaches would appear to be supported by most Electronic
> Documents,  and browsing and searching of help functions would appear to
> allow locating major sections in software as well.
> Note: Modal dialog boxes by their nature are considered part of a process
> that you can not navigate away from and must completed or cancelled before
> continuing.
> I don't see how one locates a "set of user interface elements" within a
> "software program".  This set could be not a single window but a collection
> of windows; such collections aren't generally named entities one can
> navigate to as a collection.
>  This ties into my concerns with 2.4.2 about what is a title of such a
> collection of windows.
> Fundamentally I believe this SC doesn't really apply to software, and I
> think the right thing to do is go back to WCAG and see if we have their
> blessing to say exactly that.
>  *GV:   can't do that.  But what we CAN do is to say that for xy there is
> no accessibility supported way to do z or something like that.  That  would
> indicate (if we determine this) that there is no way to do this for some
> major type of content.  (Or types).     (should not be some strange fringe
> case) *
> *
> *
> *Then the Access Board  and m376 can do their job.*
> *
> *
> *I'm not sure if that is true here though.    But if it is -- that is the
> way we can deal with it.
> *
> Fair enough.  Do you have any reaction to how one locates a "set of user
> interface elements" within a "software program"?  Particularly where that
> set encompasses multiple non-modal windows?  2.4.2 language has consensus,
> so we don't have to deal with the UIC question there, but fundamentally I
> see it as the same question.
*LM: Peter, the definition of "UI context" has been drafted as to avoid
thinking of "non-modal windows" as UI contexts. So in our proposal #4 we
only have to deal with either "major" windows or with modal windows. We
believed that it was feasible (and possible already done) to provide
multiple ways of reaching "major" windows and for the modal windows we
agreed that we could consider them to be "part of a process" and thus the
exception of 2.4.5 applied.*

Best regards,
Received on Sunday, 15 July 2012 22:22:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:44 UTC