High level thoughts on UI Context [was Re: User Interface Context]

Hi Mike,

[edited the To:/Cc: lines so folks don't get multiple copies]

I really like your high level thoughts / responses.  To that end, I've 
updated the subject line in case we want to have discussion of more 
"high level" or "global" issues related to UI Context vs. specific 
discussion of specific parts of it and whether/how they work with 
specific SCs...


On 7/12/2012 7:32 AM, Michael Pluke wrote:
>
> Hi everyone
>
> Late last night I took a look at Peter's detailed comments on the user 
> interface context definition and I now see a flood of other comments. 
> I hope to find the time to look through all of the comments in detail 
> myself and respond -- if I can ever escape from non-stop GotoMeeting 
> IRC hell that I seem to have entered over the last few weeks!
>
> In the meantime I have a few top-level observations that I think are 
> very important.
>
> 1)The user interface context definition is being expected to meet a 
> *very high* degree of precision of meaning. On the one hand this is 
> understandable, as:
>
> a. when it comes to people trying to understand a WCAG SC in the light 
> of this definition any deviation from perfection leads to uncertainty 
> about how it should be applied
>
> b.variations in interpretation MAY also lead to conformance claims 
> being challenged on the grounds that the SCs were not applied "correctly".
>
> On the other hand we have to consider whether any of the alternatives 
> to using such a definition are immune to the above issues. I strongly 
> doubt that any attempted understanding text on any one SC that has 
> been written so far, or that we are likely to write in the absence of 
> a user interface context definition, comes anywhere near meeting this 
> bullet-proof unambiguous status. Remember several attempted 
> understanding texts use the word "software" on its own (one can't get 
> much less precise!). We managed to do a lot better than that -- but is 
> anything written so far immune to all vagueness or possibility of 
> misinterpretation? I very much doubt it.
>

<PK> I accept this criticism - it is a fair point.  We who have concerns 
about UI Context shouldn't subject it to a higher level of scrutiny or a 
higher bar than any individual language used for any individual SCs in 
it's place.  However, I do suspect it will be generally easier to craft 
situationally-specific (SC-specific) language that can speak to how 
software behaves in that specific situation/SC than something more 
general.  The test will be to look at every SC which mentions "web page" 
and subject them to the same questions we are subjecting UI Context to.  
E.g. if we had x bits of software UI and gave them and the SC to y 
people, how many would agree/disagree on where and how that SC language 
applied.

> 2)User interface context is intended to be used instead of the term 
> web page. I have heard on numerous occasions WCAG experts in WCAG2ICT 
> stating that it is at times very difficult to say EXACTLY what is and 
> what is not a web page. Given this reality, it would be amazing if an 
> attempted software analogue of web page was much more clear and precise!
>

<PK> But an important question is whether the number of places we have 
these "at times very difficult to say" issues greater or fewer or the 
same with UI Context.  Thus far we've had that "difficult to say" 
situation come up once in one SC.  My person suspicion is that we have 
more than one already with UI Context.

>
> 3)By strenuously avoiding the use of a term that can be substituted 
> for web page, some very verbose (and almost certainly not 
> bullet-proof) understanding text is being written for each SC. These 
> texts have been written by agreeing, on the day, what that the SC 
> might mean when applied to software and then constructing unique 
> wordings around that. It is inevitable that we will on some days 
> consider some possible edge-cases that cause us to word one SC 
> understanding text one way and on another day our wording may be 
> influenced by considering different edge cases and ignoring others 
> that previously shaped our wording.
>
> There is a huge risk that this very distributed attempt to understand 
> software in the context of WCAG will lead to arbitrary variations of 
> interpretation of "software/user interface/software aspects/..." 
> between each SC. Having a single substitute term completely eliminates 
> such day-to-day, SC to SC, inconsistencies of understanding and 
> interpretation.
>

<PK> I think we have this challenge more generally - that in our first 
pass through the SCs we have all manner of language patterns that need 
to be cleaned up & unified (and simplified). While having a single "web 
page" substitution would be one part of a simplification / cutting down 
on verbosity, it won't address everything (e.g. all the places where we 
don't use that term but nonetheless have many sentences in our SC text).

But I think there is another reason for SC-unique text for those SCs 
that use the term "web page".  And that is that software UIs are 
fundamentally quite different from the more constrained world of the web 
page.  And things that are of accessibility importance in a web page may 
not be of the same importance in software - while things very closely 
related are.  Also when the user agent behaves in very constrained ways, 
you can make certain simplifying assumptions that simply aren't there in 
more generalized software UIs.  Both of those are underlying tensions 
for our work overall, not just for places that mention "web page".  But 
I think the tension is significantly greater in the "web page" ones.

> In summary, achieving completely a bullet-proof analogue for web page 
> that can be unambiguously understood for all possible edge-cases is 
> clearly totally impossible. However, in my view no such bullet-proof 
> and unambiguous solution exists when we avoid using a term to 
> substitute for web page. Indeed, I fear that the lack of precision and 
> predictability is merely masked by a lot of widely distributed and 
> lengthy understanding texts and that the net result is likely to be, 
> in practice, much worse and also a real chore for those who already 
> understand WCAG to have to read through!
>

<PK> In Gregg's e-mail introducing your work yesterday, he wrote:

    [applying this to all places that mention "web page"] Some of those
    are "closed" items  and they look fine as they are -- but we felt it
    should work there none-the-less  -- and it did seem to work there).

This suggests to me that Gregg isn't proposing re-opening those SCs that 
have achieved consensus, but that we should use those as part of an 
evaluation of the term.  Mike - your paragraph above suggests that you 
would prefer (perhaps in a pass after the first public review draft) 
that we do the global substitution everywhere and not simply for those 
not-yet-consensed SCs.  Is that the case?  How should we evaluate this 
definition?


Regards,

Peter

> Best regards
>
> Mike
>
> *From:*Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
> *Sent:* 12 July 2012 11:58
> *To:* Peter Korn
> *Cc:* Bailey, Bruce; public-wcag2ict-tf@w3.org
> *Subject:* Re: User Interface Context
>
> Hi Peter
>
> same as Kiran
>
> comments are inline -- and answered from the definition.
>
> and marked *GV: *
>
> On Jul 12, 2012, at 3:14 AM, Peter Korn wrote:
>
>
>
> Gregg,
>
> I'm still digesting & thinking through this proposed definition.  So 
> far though just reading the proposed definition, I've got several 
> concerns:
>
>  1. I'm very worried that the definition will be difficult for a broad
>     cross-section of folks to apply consistently to the same UIs (e.g.
>     given x different applications, will y different people all agree
>     on what the UI Contexts are in all x apps?).
>
> *GV:  I think the definition is pretty clear.  The only question would 
> be "what are navigation controls/mechanisms or not.   If no question 
> there they it seems to be a pretty bright line. *
>
>      1. Looking at Note 4, the dependent clause "because additional
>         information and user interface elements are just added to the
>         previously existing content" concerns me.  A non-modal dialog
>         box is a concrete example, but what about switching tabs in a
>         tabbed panel?  Expanding/collapsing tree nodes?  Are these all
>         different UI contexts?
>
> *GV:  Look at the definition.  If moving between tabs is done with 
> navigation commands then they are the same UIContext.   If not then 
> they are not.
>
> *
>
>  1. See item #1 above - will y different people looking at x different
>     situations in which UI components are added (or removed), will
>     they all agree on when this addition (or subtraction) constitutes
>     a new UI context vs. the same one as before?
>
> *GV:  People may come to different conclusions if they do not use the 
> definition -  but so far I haven't seen a problem making the decision 
> if the definition is used.
>
> *
>
> 1.
>  2. Note 6 says that "standard ribbons" aren't UI contexts.
>
> *GV:  correct
>
> *
>
>  2. It is common for these to be "tear off" ribbons that will thus
>     convert to floating windows.
>
> *GV:  correct
>
> *
>
>  2. Is a floating window part of the UI context or not?
>
> *GV:  Use the definition.  unless they are modal (which a pallet never 
> is)  they would still be part of the same UI Context.  Which is what 
> you would expect.
>
> *
>
>  2. Is switching from "attached" to "floating" a UI context change?
>
> *GV:  using the definition.  No.   Again - which is what you would 
> expect.
>
> *
>
>  2. (see items #2 and #1 above - will y different people agree on this
>     in x different situations?)
>
> *GV:  if they follow the definition they would
>
> *
>
>  2. Note: in some cases the keyboard operation of these ribbons -
>     whether attached or torn off - is unchanged.
>
> *GV:  exactly,  so that would be your first clue. *
>
>
>
> 2.
>
>
>
>
>     Note: the very fact that I have to ask these questions and am not
>     clear on the answers is an indication that the text as proposed
>     isn't ready to be unleashed on tens of thousands of engineers &
>     procurement officers to hopefully all interpret the same way in
>     all situations.
>
> *GV:  I don't quite understand why you had to ask the questions 
> though.  Am I missing something?    If you look at the definition, the 
> answers were all there I think.   Which of these questions do you 
> think was not answerable from just looking at the definition?   Or did 
> you just not trust the answer that it gave? *
>
> *GV:  (There are situations that would look identical (a tabbed 
> interface for example) but would be a change of  UI Context or not 
> depending on how you coded the interaction.  But of course it is 
> always possible to make things look alike and behave differently -- 
> including pages that look identical but are accessible or not 
> depending on how they are implemented. *
>
>
>
>  2. I think it would be very interesting to take a series of "edge
>     case" screen shots, and give this definition (or any proposed
>     successor) and those screen shots to a handful of folks, and see
>     the extent to which they agree on what the UI contexts are.
>
> *GV:  I don't think you can do it from a screen shot.  You cant answer 
> the question about whether something is modal or not for example.   
> But if you give them sample pages or setups where they can use the 
> navigation command - you can easily tell.
>
> *
>
> 2.
>
> I haven't yet had the time to try to apply them to all of the 
> provisions and "feel out they taste".  But particularly as you are 
> proposing a single term substitution globally, you should also expand 
> the list of "web page" and "set of web pages" SCs to include the AAA 
> ones as well.
>
> *GV:  Good idea.   Will add this to the page.*
>
> *GV:  I'm not sure we need to use the term "user interface context" 
>  in all the places globally to replace our current language.  Some of 
> what we have is much simpler and we don't need this term in our 
> responses if we have a simpler term that will work with that SC.  But 
> the simpler won't work everywhere. *
>
> *GV:  Of course it would be good if the term worked in all locations 
> and made sense - even if we have simpler words we can use in some of 
> them. . *
>
> *
>
> *
>
>
> Regards,
>
> Peter
>
> On 7/11/2012 5:53 PM, Bailey, Bruce wrote:
>
>     I am still in favor of trying to use a somewhat longer phrase
>     (where the individual words have their common meaning) rather
>     define a new term. Something like "within the context of the user
>     interface" instead of "on a web page".
>
>     I would also point that the proposed new definition starts off
>     with "set of..." and it is being proposed that "user interface
>     contexts" can be straight substitute for "web pages".  But we have
>     a few criteria that refer to "within a set of Web pages" that
>     expands to a set of a set!  While that may be mathematically okay,
>     I think it is a mess semantically.
>
>     As an example, here is 3.2.3 using the proposed new term:
>
>     Navigational mechanisms that are repeated on multiple User
>     Interface Contexts within a set of User Interface Contexts occur
>     in the same relative order each time they are repeated, unless a
>     change is initiated by the user.
>
>     Follows 3.2.3 using the same words but avoiding the new term per se:
>
>     Navigational mechanisms that are repeated in the user interface
>     within the context of a set of user interfaces occur in the same
>     relative order each time they are repeated, unless a change is
>     initiated by the user.
>
>     Follows is success criterion 3.2.3 with the proposed /definition
>     /for "User Interface Contexts" substituted for "Web pages":
>
>     Navigational mechanisms that are repeated on multiple sets of user
>     interface elements and the presented information within a product
>     that are available to a user at any point in time, where the sets
>     are limited to only those that can be reached using navigation
>     commands within the product, and without using any activation
>     commands within a set of sets of user interface elements and the
>     presented information within a product that are available to a
>     user at any point in time, where the sets are limited to only
>     those that can be reached using navigation commands within the
>     product, and without using any activation commands occur in the
>     same relative order each time they are repeated, unless a change
>     is initiated by the user.
>
>     In short, unless we look at the results of the SC with the
>     definition substituted in, I think we are likely to overlook
>     problems with inventing a new term.
>
> -- 
> <oracle_sig_logo.gif> <http://www.oracle.com/>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 <tel:+1%20650%205069522>
> 500 Oracle Parkway | Redwood City, CA 94065
> <green-for-email-sig_0.gif> <http://www.oracle.com/commitment> Oracle 
> is committed to developing practices and products that help protect 
> the environment
>

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