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

RE: User Interface Context

From: Michael Pluke <Mike.Pluke@castle-consult.com>
Date: Thu, 12 Jul 2012 10:32:27 -0400
To: Gregg Vanderheiden <gv@trace.wisc.edu>, Peter Korn <peter.korn@oracle.com>
CC: "Bailey, Bruce" <Bailey@Access-Board.gov>, "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>
Message-ID: <5735ED0D92A3E6469F161EB41E7C28A81D1B9817BA@MAILR001.mail.lan>
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.

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!

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.

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!

Best regards


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:


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.

 2.  Note 6 says that "standard ribbons" aren't UI contexts.
GV:  correct

 1.  It is common for these to be "tear off" ribbons that will thus convert to floating windows.
GV:  correct

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

 1.  Is switching from "attached" to "floating" a UI context change?
GV:  using the definition.  No.   Again - which is what you would expect.

 1.  (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

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

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.

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


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



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.

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
Received on Thursday, 12 July 2012 14:33:17 UTC

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