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

RE: User Interface Context

From: Hoffman, Allen <Allen.Hoffman@HQ.DHS.GOV>
Date: Thu, 12 Jul 2012 12:58:01 +0000
To: Gregg Vanderheiden <gv@trace.wisc.edu>
CC: Peter Korn <peter.korn@oracle.com>, "Bailey, Bruce" <Bailey@Access-Board.gov>, "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>
Message-ID: <9F7B0040F7A7C4428E160959229DE9F3018B4A70@D2ASEPRSH126.DSA.DHS>
I like that a lot more.


From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
Sent: Thursday, July 12, 2012 8:46 AM
To: Hoffman, Allen
Cc: Peter Korn; Bailey, Bruce; public-wcag2ict-tf@w3.org
Subject: Re: User Interface Context




On Jul 12, 2012, at 2:34 PM, Hoffman, Allen wrote:


Ugh:
You write:

Menus are not UI Contexts all by themselves.  They are just part of the larger UI context.    Ditto with ribbons.    Which makes sense if you think about it.   Many of the menu items actually don't make any sense except in the context of the overall UI Context.   Print, font, etc

So, can you give examples of the reverse?
GV:  not sure what you mean?


For example when writing this message if I hit alt I get access to an Outlook ribbon, one of which is a tab for help.
GV:  OK - so that is part of your UI context -- which makes sense because as I look at the page -- those are some of the controls I have immediately available to me.  That I see and are part of the interface available to me.

however the help itself is not currently part of the UI context because I have to hit an action key (mouseclick or spacebar or return) to get to the help.




If we associate anything like this with a subjective "is it associated", or "only scoped with" kind of attribute we will have a very cognitively difficult and subjectively interpretable definition.

GV:  right.  but we don't use those subjective terms.  Because they would lead to just that problem.




Can we make this less complicated and still follow our intent?

GV:  less complicated  Hmmmm.   Yes I think we can.   How about this?  (same  meaning but less complicated).

"User interface context
set of user interface elements and the presented information within a product that can be accessed using only navigation commands."






From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
Sent: Thursday, July 12, 2012 8:30 AM
To: Hoffman, Allen
Cc: Peter Korn; Bailey, Bruce; public-wcag2ict-tf@w3.org<mailto:public-wcag2ict-tf@w3.org>
Subject: Re: User Interface Context


Gregg
--------------------------------------------------------

On Jul 12, 2012, at 2:12 PM, Hoffman, Allen wrote:



Let me write a description for dummies and see if anyone thinks it is on the right track.

User interface context refers to the user interface element, and associated surrounding elements associated with active operation or "interaction" with the ICT.  Interface elements which can be navigated to using standard navigation commands from the underlying platform are not user interface contexts.  (huh)?

Not sure what you are trying to do or say here.  But you are using some rules that are not part of the definition.

User interface context is simply all the information and user interface elements that you can get to using only navigation commands.

So in your example (and by definition)  - the interface elements you can navigate to are part of the UIC.


You have caveats about activation which I think I'm fine with, but I am a bit baffled with the whole discussion of how menus which can be navigated to with standard navigation controls are not themselves user interaction contexts.  I'm not following the ribbon discussion yet either.

Menus are not UI Contexts all by themselves.  They are just part of the larger UI context.    Ditto with ribbons.    Which makes sense if you think about it.   Many of the menu items actually don't make any sense except in the context of the overall UI Context.   Print, font, etc







From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
Sent: Thursday, July 12, 2012 6:58 AM
To: Peter Korn
Cc: Bailey, Bruce; public-wcag2ict-tf@w3.org<mailto: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




  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.





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




  1.
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
Received on Thursday, 12 July 2012 12:58:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 12 July 2012 12:58:44 GMT