Re: UAWG Action 727 - Write glossary item for top-level viewport

Hi! I appreciate the effort and recognize the need to define "outline view" and "source view", but here are some things we might want to consider. The executive summary is:
(1) I think we can use a much simpler definition of "viewport" that's only about onscreen regions;
(2) I don't think we need to define "view", only "outline view" and "source view", and maybe "hierarchical view"; but
(3) where we go with the proposals below. there are some corrections, and some other paragraphs we'll have to change to match the new definitions; and
(4) we should clarify the SC that says "views that render text".


    1. A few high-level thoughts on defining "viewport":


First, the current draft has 16 SC using the term "viewport", and in every single case it refers only to graphical, onscreen viewports. The definition says it includes paper and audio, but we don't have any SC where that that applies. Therefore for the purposes of this document can't we limit viewport to mean only the graphical, onscreen variety? That could allow us to re-simplify things, getting back closer to the older, much less complicated definitions used in UAAG 1.0 and WCAG 2.0. (It's also noteworthy that while WCAG 2.0 defines the term "viewport", it doesn't use it except in the definitions of "change of context" and on "a full-screen window". It is also used it in one additional place in the Understanding document, in a way that would apply to both onscreen and printed output, but not audio output.)

Second, but related, is that I'm concerned that the proposed new wordings are much more complicated than previous versions. I think we can avoid making them that complex and confusing.

Third, a few other ways to think about viewports: (1) you can think of a viewport as separate from the medium to which its rendered, and thus you wouldn't have to say confusingly that a piece of paper is a viewport any more than a region of pixels on the screen is one, rather that those are both places where viewports may be rendered. (2) I think of a viewport as something where content is rendered or manipulated more or less separately from its surroundings. For example, in HTML a normal div is not a separate viewport, but if its content grows to exceed the div's size, then it can suddenly become separate (nested) viewport, certainly when it has overflow:scroll, overflow:auto, or overflow:visible, and arguably if it has overflow:hidden.

Thus, perhaps viewports can be something like "an onscreen region where content is rendered", or "an onscreen region where content is rendered to some extent independently of its surroundings"?



    2. A high-level thought about defining the noun "view":


The document uses "Source View" only in the title of 1.10.1, "outline view" in 1.10.2 and 1.10.3, "views that render text" in 2.1.7, hierarchical/outline view" in 2.5.7, and "state or view" in 3.2.2,. That's so few that we may not need to define the term "view". We could just define "source view", "hierarchical view", and "outline view", and easily rephrase 2.1.7 to avoid using the naked "view", such as changing "Views that render text" to "Where textual content is rendered" (but see the other note about 2.1.7 below), and similarly with 3.2.2 (but see my note about that, below, too.)




    3. All that being said, to the extent we want to go with the proposals below, here are some specific notes about their wording:


If "view" is defined as "a user interface function that lets users interact with web content" wouldn't a Submit button would be a view, as would the Tab key for navigation, Ctrl+A to Select All, ad infinitum? You could address that problem by changing the definition, or by reducing "view" from a defined term to a loose category, leaving the more specific phrases such as "rendered views" as defined terms.

Also, in your definitions of "rendered view" and "source view" you're using "render" in a different way than I would. I would say that any time the user agent presents something to the user it was rendering it, regardless of whether it was processed according to some rules or scripts (e.g. HTML and CSS), or presented essentially unmodified (e.g. plain text, images, or markup language source code).

Minor, but in the definition of outline view you might say "labels *or placeholders* for...", since it may want to present something for important structural elements that lack labels in the specifically defined sense.

Some of the terms, such as "property view" and "automatically advancing viewport", aren't used in the document, so do we really want to define them, or do they just introduce unneeded complexity?

Where it says "UAAG 2.0 recognizes a variety of approaches to presenting the content in a view:", you might reword slightly to clarify whether it's a comprehensive list or a list of examples, e.g. "UAAG 2.0 recognizes a variety of approaches to presenting the content in a view, such as:" vs. "UAAG 2.0 recognizes the following approaches to presenting the content in a view:".

"The part of a view that the user agent is currently presenting to the user, such that the user can attend to any part of it without further action (scrolling, etc.) by the user agent" is OK I guess, but it confused me when I first read it, and it took a few tries before I understood your meaning. My first interpretation was that it was referring to the portion of the content that's currently visible in the viewport, i.e. the part you can attend to without scrolling, which I knew could not be what you meant.

The definition of view has a few typos: ". :", and "on" where it should be "one".

Might acknowledge that an application can have multiple top-level viewports (e.g. a browser can have multiple top-level windows, each of which might have its own set of tabbed viewports). Thus, perhaps instead of "The highest-level viewport in a user agent application" it would be "The highest-level viewports in a user agent application", or "A user agent viewport that is not contained within another of the same user agent's viewports".

I don't see the phrase "top-level content viewports (e.g. windows or tabs)" in the current draft to replace.

Replacing "graphical" with "onscreen" makes a lot of sense if we really have have to consider printed or audio output to be viewports.

If we define view we'll have to change the title of 3.3.4 ("Centralized View") to avoid using the word in a different way, and the same with 3.2.2 Back Button ("The user can return to a previous state or view using a navigational back button or its equivalent.").


    4. And only loosely related:


Re "2.1.7 Follow Text Keyboard Conventions: Views that render text support the standard text area conventions for the operating environment. (Level A) ## DONE TPAC", should we do something to clarify that things which render text are not all text areas? For example outline views presented as tree controls, while they render text taken from the content, would be expected to support standard *tree control* conventions of the operating environment, not "standard *text area* conventions for the operating environment".

     Thanks,
     Greg

-------- Original Message  --------
Subject: Re: UAWG Action 727 - Write glossary item for top-level viewport
From: Kim Patch <kim@redstartsystems.com>
To: Richards, Jan <jrichards@ocadu.ca>
Cc: "w3c-wai-ua@w3.org" <w3c-wai-ua@w3.org>
Date: 4/27/2012 7:46 AM
> Nice.
>
> 1. Minor editorial comment -- there's a word left out near the end of the outline views sentence:
>
> Original:
> - outline views: The view presents only a subset of the rendered content, composed of labels for important structural. The important...
>
> Corrected:
> - outline views: The view presents only a subset of the rendered content, composed of labels for important structural *elements*. The important structural...
>
>
> 2. Suggestion: I'd like to see the ability to enlarge a viewport be a choice we mention in addition to scrollbars (when screen real estate permits, enlarging is often better for cognitive and mobility reasons -- you can see more of the content at once, and you can cut down on scrolling actions).
>
> Original:
> Note 1: When the viewport is smaller in extent than the content it is presenting, user agents typically provide mechanisms for the user to bring the occluded content into the viewport (e.g., onscreen scrollbars, printed page turning, audio advance and rewind).
> Suggested change:
> Note 1: When the viewport is smaller in extent than the content it is presenting, user agents typically provide mechanisms for the user to bring the occluded content into the viewport (e.g., onscreen scrollbars *and resizzable viewports*, printed page turning, audio advance and rewind).
>
> Cheers,
> Kim
>
> On 4/26/2012 5:09 PM, Richards, Jan wrote:
>> https://www.w3.org/WAI/UA/tracker/actions/727
>>
>> It seemed so easy...
>>
>> It turns out that there already is a definition, but it doesn't mention rendering content and view/viewport as a whole is a bit bloated, so I decided to dive in and
>> attempt a major rewording (including bringing in the ATAG 2.0 term "view" -http://www.w3.org/TR/ATAG20/#def-View). I'm actually quite happy with how it has finally put audio and printed viewports on a coherent footing:
>>
>> VIEW: A user interface function that lets users interact with web content. UAAG 2.0 recognizes a variety of approaches to presenting the content in a view:
>> - rendered views: The content is presented in rendered form, typically according to the web content technology specification. This is the default view of most user agents.
>> - source views: The content is presented in unrendered form. The source view may be plain text (i.e., "View Source") or it may include some other organization (e.g., presenting the markup in a tree).
>> - outline views: The view presents only a subset of the rendered content, composed of labels for important structural. The important structural elements will depend on the web content technology, but may include headings, table captions, and content sections.
>> - property views: Only selected properties of the content are presented, separate from their source or rendered forms (e.g., image properties, JavaScript errors).
>>
>> VIEWPORT
>> The part of a view that the user agent is currently presenting to the user, such that the user can attend to any part of it without further action (scrolling, etc.) by the user agent. : A user agent may include more than on viewport and they can be onscreen (e.g., windows, frames, panes, dialog boxes), printed (e.g. ink on paper, [ed. branded on cattle]), audio (e.g., sound from a speaker) or tactile (e.g. state of a Braille display). [ed. I'm assuming olfactory UIs are still not prime-time]
>> - NESTED Viewport: A viewport that is contained within another viewport (e.g. a frame within a document).
>> - TOP-LEVEL (USER AGENT) VIEWPORT: The highest-level viewport in a user agent application.
>> - AUTOMATICALLY-ADVANCING Viewport:  Some viewports automatically advance in one or more dimension (spatially or temporally). Audio viewports typically advance automatically (temporally), otherwise they would not produce coherent output, and so do some onscreen viewports (e.g. rendering video or animations or auto-scrolling) and tactile viewports.
>> Note 1: When the viewport is smaller in extent than the content it is presenting, user agents typically provide mechanisms for the user to bring the occluded content into the viewport (e.g., onscreen scrollbars, printed page turning, audio advance and rewind).
>> Note 2: Because user agent applications can be nested, the top-level viewport in a nested user agent will not be the top-level viewport in the full user agent stack.
>> Note 3: The user agent's own user interface controls (menus, alerts, etc.) are not considered viewports, though if the user agent is nested the user interface controls  may in fact be implemented using viewports of the higher-level user agent.
>>
>> Ed. So we would replace "top-level content viewports (e.g. windows or tabs)" in the document with "top-level user agent viewports"
>> Ed. We should also replace "Graphical" in most instances with "onscreen"
>>
>> CURRENT WORDING:
>> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120419/#def-viewport
>>
>> Cheers,
>> Jan
>>
>>
>>
>
> -- 
> ___________________________________________________
>
> Kimberly Patch
> President
> Redstart Systems, Inc.
> (617) 325-3966
> kim@redstartsystems.com
>
> www.redstartsystems.com <http://www.redstartsystems.com>
> - making speech fly
>
> Blog: Patch on Speech
> +Kim Patch
> Twitter: RedstartSystems
> www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
> ___________________________________________________