W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2008

Re: Attempt to simplify and harmonize "content display" vs. "chrome" distinction in ATAG2 and UAAG2

From: Simon Harper <simon.harper@manchester.ac.uk>
Date: Mon, 14 Jul 2008 09:19:26 +0100
Message-Id: <479E7A2F-9043-4291-B1A5-10E735075C44@manchester.ac.uk>
Cc: Al Gilman <Alfred.S.Gilman@ieee.org>, WAI-UA list <w3c-wai-ua@w3.org>
To: Jan Richards <jan.richards@utoronto.ca>

Hi there,

So forgive me if my newbie comments seem naive but...

If we think there is a convergence of control and access via the  
chrome, content presentation, and client side programatic  
manipulation, and that this will be intensified in the future; why  
are we trying to make a distinction here - why are we not just using  
a catch-all term to describe all functionality and presentational  
components exposed to the user, regardless of how or when they are  


Simon Harper
University of Manchester (UK)

Human Centred Web Lab: http://hcw.cs.manchester.ac.uk
My Site: http://hcw.cs.manchester.ac.uk/people/harper/
My Diary (iCal): http://hcw.cs.manchester.ac.uk/diaries/SimonHarper.ics

+----------------------[ NEW &  
INTERESTING ]--------------------------------------+
   ASSETS 2008                . 13-15 Oct 2008 . http:// 

On 11 Jul 2008, at 14:10, Jan Richards wrote:

> Hi Al,
> Thanks for your thoughts. I'm actually in agreement with you.
> As you say, there are many places where a "bright line" is  
> impossible to draw, but to me there are places it can be and in  
> doing so clarify the requirements.
> In one part of your message you say:
> > To me, the only clean statement is something like "features and
> > functions" which the UA presents to the user through the UI that are
> > independent of the content vs. those that reflect an  
> interpretation of
> > the content.
> This is what I'm trying to get at (e.g. that for a browser or  
> authoring tool rendering an image with no alt is ok if that image  
> is part of the content produced by the author, but not ok if the  
> image is in the tool's own interface). I'm definitely NOT stuck on  
> layout rectangles.
> In fact in my post yesterday (http://lists.w3.org/Archives/Public/ 
> w3c-wai-au/2008JulSep/0017.html) one of my suggestions is "UI  
> independent on content" vs. "UI dependent of content" which is  
> quite similar to what you say: "UI that are independent of the  
> content vs. those that reflect an interpretation of the content".
> Cheers,
> Jan
> Al Gilman wrote:
>> ** summary
>> Keying success criteria to this binary distinction, which is a  
>> [gross?] approximation
>> in my eyes and perhaps fading in the Web, leaves me uncomfortable.
>> Maybe I can't see the forest for the trees, being too close to a  
>> data-engineering-driven
>> view of Web operations (including the UI).
>> Sorry this is so long and replete with arcana.  But I felt I had  
>> to say something.
>> On 7 Jul 2008, at 5:04 PM, Jan Richards wrote:
>>> Hi all,
>>> Both ATAG2 and UAAG2 often require specific terms to distinguish  
>>> the part of the user interface that reflects the content being  
>>> editing/viewed and the part that is the software's own. For some  
>>> time we've tried using the terms "content display" and "chrome",  
>>> but "chrome" is especially off-putting for people. Also the fact  
>>> the "chrome" covers help documentation, which might be HTML pages  
>>> is also confusing.
>> There is a problem with using the terminology 'content views' or  
>> even 'the *part* of the UI' to communicate this distinction.
>> To me, the only clean statement is something like "features and  
>> functions" which the UA presents to the user through the UI that  
>> are independent of the content vs. those that reflect an  
>> interpretation of the content.   In other words, properties of  
>> least-discernable objects in the UI, not layout rectangles.
>> You are using one heavily-used presentation concept to identify a  
>> binary selector, where the truth revolves around selectors over a  
>> richer space of information including multiple possible answers to  
>> the question "With whom am I talking, here?"
>> lurking in the background on any such discussion are two big  
>> trends that do not augur well for making this particular binary  
>> distinction a prime feature in the guidelines:
>> a) the push to make the content look and feel like the OS UI  
>> (which the chrome already evinces).
>> b) the shift in user attention more and more into the WebApp in  
>> the content
>> at the expense of any attention paid to the chrome.
>> There are important functions where it is impossible to draw a  
>> bright line
>> between chrome and content presentation, as in the requirement to  
>> let the
>> user know where the focus is.  Or the 'visited' property.
>> Further, even where the information is from the application alone,  
>> we need to develop ways to present a distinction to the user as to  
>> what information is assured by the security sub-system of the  
>> user's computer (hardware and software), and not just "from the  
>> browser."  For the eyes-free browser, the distinction may be in  
>> what the user asks, and not solely in how the system presents  
>> information.
>> On the authoring side there are edit and preview views that both  
>> present page content but satisfy different profiles of success  
>> criteria.
>> To get at what is actually going on one would have to look at  
>> where UI information is coming from (author, browser, history,  
>> rating service, virtual AT service, ...) and where UI actions are  
>> going to (interaction state of local document copy, server,  
>> OS, ...), and how this interacts with different success criteria.   
>> Not just 'some author dependency' v. 'no author dependency.'
>> Unfortunately, this sounds like it is leading us straight back to  
>> the Gordian knot of "merging XAG and WCAG," bringing together the  
>> user experience and the Web architecture enabling that user  
>> experience and re-factoring our work according to somewhat  
>> different aspects.  That we've never been able to mount critical  
>> mass behind a project to do.
>> Al
>>> So here's another terminological try (note: [/] denotes AU/UA  
>>> versions)...
>>> The display and control mechanism that [authors/people] use to  
>>> communicate with and operate the [authoring tool/user agent]  
>>> software. A user interface may be non-Web-based or Web-based or a  
>>> combination (e.g., a non-Web-based [authoring tool/browser] might  
>>> have on-line help pages). For the purposes of these guidelines,  
>>> there is an important distinction between (1) *CONTENT VIEW(S)*  
>>> the accessibility of which often depends to some extent on the  
>>> content being [edited/rendered, played or executed] and (2) the  
>>> rest of the [authoring tool/user agent] user interface (referred  
>>> accessibility of which does not depend on the content being  
>>> [edited/rendered].
>>> The [authoring tool/user agent] user interface functionality that  
>>> presents content for user interaction. Content views may be  
>>> distinguished by:
>>> (1) *Editability*: some content views allow authors to modify the  
>>> content as displayed (e.g., [an "editing view"/an editable  
>>> "source view"]), while others do not (e.g., [a "preview" feature/ 
>>> the rendered view typical of browsers, a read-only "source view"]).
>>> (2) *Nature of rendering*:
>>> (a) *instruction level content views* present the content
>>> encoding instructions in non-rendered form (e.g., [plain text  
>>> editing views, form-based editing views that provide direct  
>>> access to the instructions such as selecting attribute  
>>> values/"source view"]).
>>> (b) *rendered content views* result from fully or partially  
>>> rendering, playing, or executing the content. The broad range of  
>>> potential renderings covers conventional (often called "WYSIWYG")  
>>> renderings to less conventional renderings such as a graphical  
>>> wavefront of an audio file or the displays of text-only browsers.  
>>> *Partial renderings* are those in which some aspects of the  
>>> content are rendered, played, or executed, but not others (e.g.,  
>>> a frame-by-frame video [editor/player] rendering the graphical  
>>> aspect, but not the temporal aspect, of a video.
>>> (c) *meta content views* present properties, metadata or other more
>>> abstract information about the content (e.g., [a content  
>>> management system that creates a Web-based calendar based on the  
>>> author selecting only the month and year/a "page properties"  
>>> feature]).
>>> All parts of the user interface other than the content view(s).  
>>> Includes all user interface components that surround, underlie,  
>>> or superimpose upon content views (e.g., text areas, menus bars,  
>>> rulers, pop-up context menus) and also other Web content made  
>>> available to the author/user by the developer of the [authoring  
>>> tool/user agent] (e.g. help files).
>>> CONTENT VIEWS" as a way forward?
>>> Cheers,
>>> Jan
> -- 
> Jan Richards, M.Sc.
> User Interface Design Specialist
> Adaptive Technology Resource Centre (ATRC)
> Faculty of Information (i-school)
> University of Toronto
>   Email: jan.richards@utoronto.ca
>   Web:   http://jan.atrc.utoronto.ca
>   Phone: 416-946-7060
>   Fax:   416-971-2896
Received on Monday, 14 July 2008 20:44:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:36 UTC