Re: Interaction Context + UI + Content

Mike,

I think the M376 definition of "interaction context" is far less 
unwieldy than our draft definitions of "user interaction context".  
However... I am still concerned that it is still sufficiently imprecise 
that software developers & procurement officers won't be able to apply 
it uniformly in a variety of software situations.

At the same time, except perhaps for 2.4.1 Bypass Blocks 
<https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/241-bypass-blocks> 
& 2.4.2 Page Titled 
<https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/242-page-titled> 
& 2.4.5 Multiple Ways 
<https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/245-multiple-ways> 
(and maybe, perhaps, 3.2.3 Consistent Navigation 
<https://sites.google.com/site/wcag2ict/home/3-understandable/32-make-web-pages-appear-and-operate-in-predictable-ways/323-consistent-navigation>) 
I'm not so sure that any such lack of uniformity hurts us.  Particularly 
if we add a further note along the lines of: "Note: it is not possible 
for any aspect of the software user interface to NOT be in an 
interaction context; all software UIs can always be decomposed into one 
or more interaction contexts."  For example, having 2.3.1 Three Flashes 
or Below Threshold 
<https://sites.google.com/site/wcag2ict/home/2-operable/23-do-not-design-content-in-a-way-that-is-known-to-cause-seizures/231-three-flashes-or-below-threshold>tied 
to an 'interaction context' (as you do in M376), it doesn't matter if 
one procurement officer says some software consists of 2 ICs whereas 
another says 1 or 3 - NO IC can violate this (or as we say, no part of 
the "software" can violate it) or it is a violation.  There might be 
confusion where there is a violation with regards to conformance 
statements...  But the conformance discussion is for another time.


Mike - do you have any sense as to the receptivity of the M376 folks to 
a Note along the lines that I suggested above?


Separately, regarding Mike's Conclusion #6 below, I frankly don't see 
the "software ambiguity" as any better/worse than what I see as the 
"interaction context ambiguity".  It has the same challenges for the 
same handful of SCs (2.4.1, 2.4.2, 2.4.5, and maybe 3.2.3), and is the 
same non-issue for the rest => except when it comes to a discussion of 
detailed conformance reporting (what subset of an entire "software 
package" is there a conformance failure on if one app in that package is 
the source of the failure; vs. what subset of the entire "software 
package" is there a conformance failure on if one interaction context in 
that package is the source of the failure).


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 guidesthe 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 WCAG2ICTthat 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 eachSC 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 thecurrent 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 506 9522 <tel:+1%20650%20506%209522>
Oracle Corporate Architecture Group
500 Oracle Parkway | Redwood City, CA 94065
------------------------------------------------------------------------
Note: @sun.com e-mail addresses will shortly no longer function; be sure 
to use: peter.korn@oracle.com to reach me
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment