RE: Interaction Context + UI + Content

I have had several comments from folks who do usability that the term context has meaning there that causes them cognitive difficulty with UI context for our purposes.  Sigh.  Doesn't give me any cognitive problems, other than following our own challenges in figuring out how to say what we all think we know.

I think one challenge we seem to be having is that in some situations no matter what term we agree on, with an associated definition, the variety of interfaces outside the Web environment may break it, or cause so much ambiguity as to make it less useful than it might otherwise be.  Notwithstanding this however, I think the term UI context "feels" better to me from a plain-language than "top-level frame", which from a programming perspective "feels" better to me.

I think the problem we are having with 2.4.5 for documents is that even when we apply it it either requires authors to change the content itself, or rely on outside functionality to provide alternatives.  What are the analogs to the sufficient we provide in WCAG now which would be acceptable outside the Web scoping?






From: Michael Pluke [mailto:Mike.Pluke@castle-consult.com]
Sent: Sunday, August 12, 2012 2:12 PM
To: Peter Korn
Cc: public-wcag2ict-tf@w3.org
Subject: RE: Interaction Context + UI + Content

Hi

I agree that if the definition were heavily tied to user intent then it would be a big problem. I do not believe that it is.

I believe that there is a reasonable and safe default assumption for example 1 that 1 window = 1 task.  So there must automatically be two ICs (no mind-reading required). Your explanation, below, of the identical windows reveals that this assumption is correct. I only mentioned intent as I could not understand why a person would deliberately create two identical windows. Was this part of some bizarre meta-task that I could not imagine? If such a thing was possible then maybe the reasonable safe assumption, that does not require intent to be judged, would not be correct. Fortunately this weird exception is not the case - all is well - judging of intent is not required!

However, the fact that the definition revolves around user tasks is a potential weakness, as it is always possible that there may be some edge cases where not everyone will agree how much of the software is actually supporting the user task. But it is this same abstraction that makes the definition very flexible in terms of not tying it to any presumed UIs architectures or implementations. The definition works well for all types of UI, including voice interfaces - where the IC would be a single dialogue step.

It  would be nice if we can improve all of our definitions to minimise edge-case ambiguities. However, in all cases where one attempts to describe a group of things (UIs) using global terms ("software", "software UI", "interaction context", "top-level frame") such ambiguities will always arise. This is not a defeatist statement but a simple fact recognised nearly 2400 years ago by Aristotle. Attempting to infinitely refine things to remove such ambiguity will be a fruitless task and not something that Aristotle believed that an "educated man" would pursue too far!

I think that in many instances the interaction context and the "top level frame" may well be identical. But I am not sure we have a definition for "top level frame" and to me it seems to infer a certain type of UI (definitely hierarchical and sounds too much like a visual interface). I fear that there may be many people who will not understand what the top-level frame may be in their UI. So far I am probably one of them.

I will try to find the time to look through all of the examples. I think you are right about what I said, but if I did this was wrong as I should have said "nearly all of your examples appear to be one IC". I did a random sample and of all the ones I sampled I only seemed to see one IC - but the first one is definitely two ICs.

Best regards

Mike



From: Peter Korn [mailto:peter.korn@oracle.com]
Sent: 11 August 2012 20:39
To: Michael Pluke
Cc: public-wcag2ict-tf@w3.org
Subject: Re: Interaction Context + UI + Content

Mike,
On 8/11/2012 9:34 AM, Michael Pluke wrote:
Peter

Example 1 is a very strange example - with two editing windows containing identical content - why?

The "story subtext" behind this set of examples (read the text the author is composing) is creating a series of letters to a bunch of different folks, all with essentially the same text.  Before customizing the second document (see "UI Context change?" example 5<https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-5-user-changed-text-in-document> and example 6<https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-6-user-changed-text-title>), there is a moment in time when there are two documents windows open with the same content (in the middle of the copy/paste/edit cycle).

I put up an example with exactly the same content to tease out (and potentially trip up) developers as they try to figure out whether having the content the same makes any difference or not.  Would the answer be different if the content were different?  Note that the window titles are different (would the answer be different if the window titles were the same? - see How many example #6<https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/how-many-example-6-two-copies-of-the-same-control-panel-open>).  If a significant percentage of folks come up with different answers from the same definition and with the same examples, it points to a potential weakness (and area for possible improvement) in our definitions.



I think that, of your many examples, this one really consists of two interaction contexts (1 per window). Normally you would expect that the user would be editing two different documents in two windows - then the two tasks would be different (Editing document 1 and editing document 2). In that case, the definition clearly suggests that there are two interaction contexts.

Where the user has, rather perversely, chosen to open two windows on the same document it is very hard to understand what the user's intended task was! So, despite the strange example, I think that a rational analysis of the example is that there would still be two interaction contexts irrespective of the odd user behaviour.

It troubles me a little bit that your application of "interaction context" seems to be tied to user intent.  Discerning intent can be difficult.

Would you do me a favor - to through all of the first set of examples 1-10 and tell me how many "interaction contexts" there are each?  My recollection from a comment you made verbally last week was that you thought there was only 1 "interaction context" for all 1-10, so your now saying there are two for example 1 has me a little confused.  "interaction context" is now feeling more like "top level frame"...


As there are two interaction contexts I would expect that each should carry a title (the last option in your email). I would normally expect that the title of each interaction context would be the title of the document, in this case "Untitled Document 1" and "Untitled Document 2" seem to be reasonable names for each IC.

Yup.  That follows from there being two ICs.


Peter


Best regards

Mike




From: Peter Korn [mailto:peter.korn@oracle.com]
Sent: 11 August 2012 02:11
To: Michael Pluke
Cc: public-wcag2ict-tf@w3.org<mailto:public-wcag2ict-tf@w3.org>
Subject: Re: Interaction Context + UI + Content

Mike,

I've been thinking more about "interaction context" - and also looking at the M376 document "EN 301 459 v005.doc<http://www.mandate376.eu/doc/EN301549V005.zip>".

As I read the definition and also from your explanations, the "how many Example 1<https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/how-many-two-document-windows>" example showing an application with two non-modal windows open would consist of a single "interaction context".  Yes?

SC 2.4.2 Page Titled states that each each web page (nee "interaction context") must have a title.

On page 21 of EN 301 459 v005.doc<http://www.mandate376.eu/doc/EN301549V005.zip> there is an "Applicability note" for 2.4.2 that reads: "Most interaction contexts (windows, dialogue boxes...) have titles in a majority of platforms. For those interaction contexts with no platform support for titles, the first words they contain may be considered their titles."

So... what is the title of the interaction context of the pair of top-level, non-modal windows show in in Example 1<https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/how-many-two-document-windows>?  Is it the (not displayed) name of the application?  Or is it that really two interaction contexts are being displayed (and so each gets its own title)?


Peter

On 8/9/2012 2:28 PM, Michael Pluke wrote:
Hello everyone

In the "interaction context" sub-group we have been debating for some time issues related to the need for and definition of a concept such as "interaction context" or "User interface context". In this email I'd like to clarify some of the reasons why we find ourselves in this position.

The primary starting point for these discussions arose because the Mandate 376 people introduced this concept in our last two drafts. Ever since the  second US Section 508 ANPRM arrived our team have spent very many person weeks of effort trying to figure out how we can support the following statement:

"Software that provides a user interface shall conform to Level A and Level AA Success Criteria as defined by the Conformance Requirements specified in WCAG 2.0"

We immediately started looking for mappings between Web concepts and software concepts. As WCAG 2.0 conformance and Success Criteria are based around the Web page, we immediately looked to identify something that could directly map to a Web page. After a lot of discussion and consideration of alternatives (in the process of which we rejected simple terms like "software") we arrived at:

"interaction context: that part of the user interface of a system in which the users interact with all the functions, containers, and information needed for carrying out some particular task or set of interrelated tasks

NOTE:   An interaction context can include but is not limited to things such as, the complete software window, a dialog box, message box, voice dialogue step, etc."

The equivalence that we hope that we have achieved leads to the following:


-          A single Interaction Context (IC) is equivalent to a single Web page (in fact a web page nicely fits the M376 "interaction context" definition)

-          Most software, that can contain several ICs, actually maps to "a set of Web pages" (not a Web page). Only simple software with a single IC maps to Web page.


Taking my favourite complex application (software), MS Outlook, as an example, this contains at least four main ICs:


-          Mail;

-          Calendar;

-          Contacts;

-          Tasks.


These are clearly separate M376 ICs as they each support quite different user tasks. According to the M376 definition there will be a number of other ICs that are less obvious i.e. all of the modal dialogue boxes that can be shown when using any of the above and that impose themselves as the user task until dismissed.

There are several (even most) SCs that could actually be successfully applied to a complete set of Web pages e.g. 1.1.1 and 2.4.6 where it is required that there should be text alternatives and that headings and labels should describe topic or purpose no matter where they are in a set of Web pages. It is therefore true that these SCs could also be successfully applied to a complete set of ICs i.e. "software" or the "software UI". However, this is not what the WCAG 2.0 conformance requirements says should be done - these say that the SCs should be separately applied to each Web page - and this translates to each "interaction context".

In SCs that relate to the behaviour of one Web page in a set of Web pages, the shortcut of applying the SC to a set of Web pages (which is what "software" and "software UI" translate to) breaks down. It is for these SCs that something like IC is (probably) needed.
My Conclusions


1)      The M376 "interaction context" approach sticks much more rigidly to the WCAG 2.0 approach - so this is why it plugs straight in to the WCAG Conformance Requirements without any modification needed to those requirements.

2)      The "software" and "software UI" approach actually guides the user away from a strict interpretation of the WCAG intent as it says that SCs should be applied to something that equates to a "set of Web pages".

3)      The use of "software" and "software UI" will be inadequate for the few remaining problem SCs in WCAG2ICT that explicitly refer to "Web page". Much cleverer wording will be needed if IC is not used.

4)      However, the "software" and "software UI" approach leads to much greater efficiency and simplicity when applying many SCs to software i.e. the whole software can be tested as one piece and it does not need to be broken down into its component ICs (which could be a difficult task) in order to test.

5)      Without a term like "interaction context" WCAG2ICT may have great difficulty in addressing Conformance Requirements. It will not be possible to say how any SC should be applied as the current WCAG2ICT guidance is separately stating what each SC applies to. Some SCs apply to "software", some to "software UIs" and maybe we have other variants. We may or may not be able to rationalize this. In all cases so far, I don't think that we are scoping any of the SCs to a unit that clearly equates to an analogue of a Web page.

6)      There is fundamentally no clear boundary to what is meant by software. This means that one supplier may interpret software as a single application. Another may take it to mean a shrink-wrapped software suite. Another might take it to mean the total diverse multi-supplier software bundle that they supply! Such ambiguity is a serious problem when trying to interpret how to apply the SCs and also when trying to compare between suppliers who have interpreted "software" in a very different way. This lack of consistency in interpretation is one of the key criticisms of some people against IC - but this inconsistency could be very much greater when interpreting "software"! "Interaction context" does attempt to try to define and constrain the scope across which an SC should be applied. It appears that "software" and its variants do not get close to achieving this scoping precision.

I would like to ponder my conclusion 4, which reveals a potential weakness of the current M376 approach - but one which I hope may be addressable by a few simple statements that indicate that some SCs, that strictly apply to one IC, can be applied to the whole software for the sake of efficiency.

I think that WCAG2ICT will need to continue to ponder issues 3, 5 and 6. I will of course try to actively help in this pondering!

I would like to arrive at a situation where it is clear that M376 and WCAG2ICT are saying the same thing. M376 will not be presenting our material in exactly the same form as WCAG2ICT as this does not suit the needs of our standard (EN). Similarly, WCAG2ICT cannot adopt the M376 way of presenting its guidance as this does not meet W3Cs needs.

Best regards

Mike

PS: I believe that the current "User Interface Context (by an author)" definition is inferior to the M376 "interaction context" definition as it depends on the term "navigation commands" and relies on separately identifying "user interface elements" and "presented information". Unfortunately I think that the task of evolving the definition from its M376 roots got diverted into a string of updates to fix some supposed weaknesses that were being raised.


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

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