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

Re: Looking at SC 3.1.1 Language of Page with "UI Context"

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

I'd like to point out that proposal #4 is longer not for the use of "UI
context" but because we added a new paragraph explaining the difficulties
of meeting this success criteria in some platforms.

I might agree that for this success criterion the use of "software product"
or similar term may be more useful than using "UI context", but when Gregg,
Mike and I worked on proposal #4 it felt to us that the meaning of SC 3.1.1
still worked when using "UI contet"

So we have two issues on 3.1.1:

   1. To accept or not using "UI context" to replace "web page"
   2. To accept or not the third paragraph of proposal #4.

Best regards,
Loïc

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

>  Gregg,
>
>
>   <PK> Hi gang,
>
>
> SC *3.1.1<https://sites.google.com/site/wcag2ict/home/3-understandable/31-make-text-content-readable-and-understandable/311-language-of-page>
> ** ** *was not one we reached consensus on. We've had some discussion on
> it, and I feel that proposal #3 was getting there.
>
> 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 sixth row, but to facilitate discussion, I reiterate them here.
>
> The UIC Proposal is:
>
> This applies directly as written, and as described in INTENT from
> Understanding WCAG 2.0  (above) with "document or user interface context"
> substituted for "Web Page".
>
> Note that some document formats can use separate human languages for
> output and input purposes. In such cases both languages should be
> programmatically determinable.
>
> For software, there are some platforms and software types where there is
> no assistive technology supported method for marking the language for the
> different "user interface contexts" or for marking that the application
> doesn’t match the “local” language, as marked in the platform, and it would
> not be possible to meet this success criterion with those platforms or
> software types.
>
> NOTE: Inheritance is one common method.  For example a document or
> application provides the language that it is using and it can be assumed
> that all user interface contexts within that document or application will
> be using the same language unless it is indicated.
>
> I don't see how UI Context really helps us here.  It is unlikely that two
> UI Contexts in the same software application will have different languages.
>
>
>  *GV:  OK.  But not sure why you are raising that.*
>
>  Granularity is either at the application level (most common) or at the
> UI component and language passage level (which gets us to SC 3.1.2).
> Scoping this to software applications seems cleaner and more direct to me.
> Also easier to understand and test.
>
>
>  *GV:  Agree -*
> *
> *
> *Not sure you are correct that it can't happen lower -- but scoping at
> the application level might be possible. *
> *
> *
> *  More to the point however - is the part that starts "For
> software....".   It notes that for some technologies there is no way to
> mark language even at the Application level.    That is something we CAN do
> and is a sure sign to Access Board, M376 and others that this is something
> that at a minimum should be scoped.
> *
>
>
> PK: Here's my key question: why do you feel UIC is better than "software
> application" for this SC?  I believe it is worse because (a) it is almost
> never the case that an application comprised of multiple UICs will have a
> different language/local for one UIC vs. another (it'll either be at a
> lower granularity and covered by 3.1.2 or it'll be the entire app); (b) UIC
> is a harder concept to understand and test for (where one stops and another
> beings) vs. "software application"; and (c) the proposal #3 on the table is
> shorter text than the UIC proposal.
>
> So why is UIC better here?  What does it gain us?  If the gain is that we
> can use UIC (almost) everywhere for simplification purposes, then we need
> to look at and evaluate the global substitution to achieve that value.
>
>
> Regards,
>
> Peter
> --
> [image: Oracle] <http://www.oracle.com>
>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 <+1%20650%205069522>
> 500 Oracle Parkway | Redwood City, CA 94065
> [image: Green Oracle] <http://www.oracle.com/commitment> Oracle is
> committed to developing practices and products that help protect the
> environment
>
>
>


-- 
---------------------------------------------------------------
Loïc Martínez-Normand
DLSIIS. Facultad de Informática
Universidad Politécnica de Madrid
Campus de Montegancedo
28660 Boadilla del Monte
Madrid
---------------------------------------------------------------
e-mail: loic@fi.upm.es
tfno: +34 91 336 74 11
---------------------------------------------------------------


green-for-email-sig_0.gif
(image/gif attachment: green-for-email-sig_0.gif)

oracle_sig_logo.gif
(image/gif attachment: oracle_sig_logo.gif)

Received on Sunday, 15 July 2012 22:13:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 15 July 2012 22:13:55 GMT