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

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
-- 
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522 <tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment