RE: Interaction Context + UI + Content

Thanks Mike... I was hoping we'd have a sort of a kick off email to our
formal discussions and I think this is a good start...

 

I agree with most of this:

 

.         There are compelling reasons to choose one term (perhaps
"interaction context", or a more friendly term that means the same thing).

.         I agree with Mike's Point 4, using a more generic term (Software
UI etc.) would make things MUCH easier to understand for those SC that don't
require a "context". I think there are only 3 SCs that actually need a
"context" (2.4.5, etc) but Mike has a good point about conformance being
based on a web page. The thing a web page has that an Interaction Context
doesn't is a URI. That's the bright line on the web (which is not so bright
in WEB 2.0). It's more fuzzy line software, not impossibly so, but hard
enough to warrant walking through the idea of a more generic term for most
SCs, to see if could work. 

 

I think we'll need about an hour to reason through and make a well thought
out decision as to whether we want to go with 

1.       one term global replacement 

2.       Simple generic term for 33 SC and only use IC when necessary for
the 3 that need it.

3.       Try to word smith the IC concept out of it completely (which would
be hard, if not impossible, but worth trying)

 

>> There is fundamentally no clear boundary to what is meant by software.

 

We could define it, either by adding a couple of words, or by a glossary, to
explain that it is only the part of the software that is presented to the
user. I'm not convinced this os a good reason to abandon a more generic term
for the majority of the SCs that don't need context.

 

So I think we should put as a top priority: Coming to a decision about 1,2,3
above

 

>From an understanding perspective I think the trade-off of an easy term for
33 of the 36 SC is worth a note on the conformance section... if we could
successfully do it.

 

Cheers

David MacDonald

 

CanAdapt Solutions Inc.

  "Enabling the Web"

www.Can-Adapt.com <http://www.can-adapt.com/> 

 

From: Michael Pluke [mailto:Mike.Pluke@castle-consult.com] 
Sent: August-09-12 5:29 PM
To: public-wcag2ict-tf@w3.org
Subject: Interaction Context + UI + Content
Importance: High

 

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. 

 

 

 

Cheers

David MacDonald

 

CanAdapt Solutions Inc.

  "Enabling the Web"

 <http://www.can-adapt.com/> www.Can-Adapt.com

 

From: Michael Pluke [mailto:Mike.Pluke@castle-consult.com] 
Sent: August-09-12 6:42 PM
To: Peter Korn; public-wcag2ict-tf@w3.org
Subject: RE: Interaction Context + UI + Content

 

Peter

 

I'll need to very carefully read your note again in the morning (when my
brain is restored). But I believe that the solution to many of the apparent
discrepancies between the pure IC approach and the grass roots "software"
approach probably lies in some well drafted notes (possibly in both M376 and
WCAG2ICT).

 

We may differ about which approach suffers from the greatest imprecision and
lack of potential uniformity, but it looks as if we are converging towards a
recognition that there is no 100% perfect solution and that the best
solution will probably be achieved by means of well worded notes that help
people to avoid getting trapped in those areas where the ambiguities exist.

 

As long as I am convinced that we have a workable solution I am reasonably
happy that I can persuade most of my team to accept a solution that improves
on what we have (and I hope that I can continue to deal effectively enough
with the few that are instinctively reticent to revisit previously taken
decisions).

 

I would like to resist any further "mine is better than yours" type
arguments regarding the ambiguities. I guess that to date I have been very
frustrated that there has been an inherent presumption that ambiguities only
exist on the IC side and that the "software" side has no problems. The
reality is quite clear that no solution is perfect and that our future
efforts should be directed towards improving the interpretation of the
IC-oriented and software-oriented ways of capturing what we need to say. 

 

I think that the proposed survey, that avoids these terminology wars, is a
very useful step in this direction. I am, for the first time, beginning to
be optimistic that we will be making some progress on the remaining SCs and
conformance.

 

Best regards

 

Mike

 

From: Peter Korn [mailto:peter.korn@oracle.com] 
Sent: 09 August 2012 23:15
To: public-wcag2ict-tf@w3.org
Subject: 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-h
elp-users-navigate-find-content-and-determine-where-they-are/241-bypass-bloc
ks>  & 2.4.2 Page Titled
<https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-h
elp-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-h
elp-users-navigate-find-content-and-determine-where-they-are/245-multiple-wa
ys>  (and maybe, perhaps, 3.2.3 Consistent Navigation
<https://sites.google.com/site/wcag2ict/home/3-understandable/32-make-web-pa
ges-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-con
tent-in-a-way-that-is-known-to-cause-seizures/231-three-flashes-or-below-thr
eshold> 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 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. 

 

 

-- 
 <http://www.oracle.com> Oracle
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 

  _____  

 <http://www.oracle.com/commitment> Green
OracleOracle is committed to developing practices and products that help
protect the environment