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

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)...
>>
>> [AUTHORING TOOL/USER AGENT] USER INTERFACE
>> 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 to as the *USER 
>> INTERFACE EXCLUDING CONTENT VIEWS*) the accessibility of which does 
>> not depend on the content being [edited/rendered].
>>
>> CONTENT VIEW
>> 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]).
>>
>> USER INTERFACE EXCLUDING CONTENT VIEWS
>> 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).
>>
>>
>>
>> Any thoughts on "CONTENT VIEW" and "USER INTERFACE EXCLUDING 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 Friday, 11 July 2008 13:09:09 UTC