W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2012

Minutes: UAWG 3 May 2012

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 3 May 2012 13:37:42 -0500
Message-ID: <CA+=z1Wknbyp9yCw7NBsJeq+uKuwxkgjk+pgzks3s9n0paZ06NQ@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
from http://www.w3.org/2012/05/03-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference
03 May 2012

See also: IRC log http://www.w3.org/2012/05/03-ua-irc

    Jeanne, Jim_Allan, kford, Greg_Lowney, Jan, Kim_Patch
    KellyFord, JimAllan


        Action-727 Glossary - Viewport
        1.5.1 needs decision on whether it is done or not - Action
item 723 on Kim
    Summary of Action Items

Summary of Action Items
[NEW] ACTION: Greg to revise 2.1.7 Follow Text Keyboard Conventions to
acknowledge not all view showing text should follow text area
conventions. [recorded in

<trackbot> Date: 03 May 2012

<kford> zakim isn't letting me enter a phone code.

<kford> and now it did.
Action-727 Glossary - Viewport

<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0053.html

Jan: the idea is to split view and viewport which had been together since 1.0.

<JAllan> IEW: 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:

<JAllan> - 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.

<JAllan> - 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

<JAllan> - 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

<JAllan> - property views: Only selected properties of the content are
presented, separate from their source or rendered forms (e.g., image
properties, JavaScript errors).


<JAllan> 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)...

<JAllan> ...or tactile (e.g. state of a Braille display). [ed. I'm
assuming olfactory UIs are still not prime-time]

<JAllan> - NESTED Viewport: A viewport that is contained within
another viewport (e.g. a frame within a document).

<JAllan> - TOP-LEVEL (USER AGENT) VVIEWPORT: The highest-level
viewport in a user agent application.

<JAllan> - 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.

<JAllan> 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).

<JAllan> 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.

<JAllan> 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.

<JAllan> Ed. So we would replace "top-level content viewports (e.g.
windows or tabs)" in the document with "top-level user agent

<JAllan> Ed. We should also replace "Graphical" in most instances with


<JAllan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120419/#def-viewport

Jan: user agents talk about views and more flexible in what that
means. There are lots of different views of Web content.
... I was really trying to wrap my head around audio because when you
listen to audio because of that first statement -- without the user
agent doing anything, but the user agent is always doing something in
audio so how does that work. Some viewports automatically advance

<JAllan> greg's comments:

Jan: I like some of the points you made especially the simplification
only looking at visual, but definition of viewport complicated and

Greg: we have 16 SCs that use viewport and they're all about on-screen.

Jan: was trying to be backwards compatible with UAAG 1 which mentions
those things

<JAllan> UAAG 10 def View, viewport

<Jan> http://www.w3.org/TR/WAI-USERAGENT/glossary.html#def-viewport

<JAllan> The user agent renders content through one or more viewports.
Viewports include windows, frames, pieces of paper, loudspeakers, and
virtual magnifying glasses. A viewport may contain another viewport
(e.g., nested frames). User agent user interface controls such as
prompts, menus, and alerts are not viewports.

<JAllan> Graphical and tactile viewports have two spatial dimensions.
A viewport may also have temporal dimensions, for instance when audio,
speech, animations, and movies are rendered. When the dimensions
(spatial or temporal) of rendered content exceed the dimensions of the
viewport, the user agent provides mechanisms such as scroll bars and
advance and rewind controls so that the user can...

<JAllan> ...access the rendered content "outside" the viewport.
Examples include: when the user can only view a portion of a large
document through a small graphical viewport, or when audio content has
already been played.

<JAllan> When several viewports coexist, only one has the current
focus at a given moment. This viewport is highlighted to make it stand

Greg: all that you really need is the first sentence of it

<JAllan> User agents may render the same content in a variety of ways;
each rendering is called a view. For instance, a user agent may allow
users to view an entire document or just a list of the document's
headers. These are two different views of the document.

<Greg> WCAG defines viewport as "object in which the user agent
presents content"..

<Jan> http://www.w3.org/TR/WCAG/#viewportdef

<Jan> http://www.w3.org/TR/WAI-USERAGENT/glossary.html#def-viewport

Greg: not perfect, but simple

Jan: how does the view then react because it's really the view that's
rendering the content

Greg: we don't use view -- do in a couple places but it would be easy
to rephrase to not use view. We could not have to worry about the word
view and therefore avoid the complexity.

Jan: a lot of them have to do with such the viewport or stretch the
thing behind the viewport such that it wraps -- the viewport is just
the portal like the window in a house that I'm seeing the view through
... , all it does is constrains the view that I'm looking at

Greg: agree that those were complicated and confusing

Jim: so outline view is the outline that appears within the viewport.
Maybe just using the word view is getting conflated with viewport

Greg: because everything is presented in a viewport, or actually not
because if you -- it can theoretically be presented as part of the
problem, but let's say you have a navigation menu which has submenus
and the whole struck for both the menus represent the view of the
document and let you navigate quickly -- so it's not a viewport
because it's all part of the chrome

Jan: I'd call that a viewport -- yes it's part of the menu but it has
a viewport around it

Greg: so some menus are viewports and others are not?

Jan: a user interface function that lets you interact with Web
content. It could be rendered, source, outline or just a property view
which is any other filtering, images or even JavaScript errors. We are
used to seeing that in a nice big window with a menu bar on top, but
you could imagine clicking on a menu and the first item on the menu is
the entire rendered page, that could happen. So...
... wherever the user agent decides to let the user interact with Web content
... that's why I like this definition, it's flexible

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0053.html

Jan: for me this is the front-line definition, the definition we
should be pointing to. Then we get very specific, deal with resize,
scroll etc. in one section

Greg: you don't want to include the submit button is if you, because
it is something that lets you interact with Web content. So you might
need to tweak the definition
... my general druthers is usually to omit definitions we don't need,
but if you want to include it and tweak it, it would be okay

Jan: could be simplified by keeping it to graphical viewport, which is
really what we mean -- it could be simplified if we want to go that

Greg: first, on screen, second, complicated stuff about who has to
take action, who doesn't -- when I read it it didn't make sense at
... just as a menu can be of you are not a view depending on what it's
representing, so t in HTML can be a viewport or not depending on
attributes and size of content -- if you have a normal paragraph not a
viewport but if it has content that is larger then it's a viewport.
... to make it work to match with our SC's that use viewport

Jan: that can fit in with the definition. We could put a note
somewhere that it needs to be the case that potentially the user agent
would have to do some action to bring the rest of it into. Otherwise
you are just looking at a view port only

Greg: everyone okay with limiting definition to on-screen?

Jeanne: where would we put audio

Greg: can we remove the step about no extra action

Jan: I'm going to try to simplify it. The user has to attend to one
corner or another -- user actions, but no user agent actions

Greg: Question of what our user agent actions. If I scroll enough
times in this viewport the Web client has to query the server for
another chunk of data -- stuff like that. That's getting to be a user
agent action.

Jan: if I touch only one right arrow that's potentially going to cause
the user agent to do something. I'm just talking about pure
perception. And keep that automatically advancing for audio because in
that case the user agent is constantly doing things.

<Jan> Jan to update the definitions to...rem non-onscreen viewports...

Greg: you use the word rendered differently than I do -- you use it
being processed in some way. I wouldn't use the word render to mean
only the cooking that doesn't happen in source view

<Greg> 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).

<JAllan> current UAAG20 definition: rendered content, rendered text

<JAllan> Rendered content is the part of content that the user agent
makes available to the user's senses of sight and hearing (and only
those senses for the purposes of UAAG 2.0). Any content that causes an
effect that may be perceived through these senses constitutes rendered
content. This includes text characters, images, style sheets, scripts,
and any other content that, once processed, may...

<JAllan> ...be perceived through sight and hearing.

<JAllan> The term "rendered text" refers to text content that is
rendered in a way that communicates information about the characters
themselves, whether visually or as synthesized speech.

<JAllan> In the context of UAAG 2.0, invisible content is content that
is not rendered but that may influence the graphical rendering (i.e.
layout) of other content. Similarly, silent content is content that is
not rendered but that may influence the audio rendering of other
content. Neither invisible nor silent content is considered rendered

Jan: what would you use to distinguish [etc. from picture

Greg: familiar with scratch.com or Lego mind storm? in that case the
source view is not just plain


<Greg> (Invented by MIT's Media Lab, by the way.)

<Jan> http://www.w3.org/TR/ATAG20/#def-Content-Renderings

Jan: I was thinking about the Lego mind storm when it was written.
There's different kinds of content rendering in a tag. There's
conventional rendering, unconventional rendering and partial
... I was trying to keep it simpler, but maybe it needs to grab the
atag complexity

Greg: would it be an unconventional rendering that would be the source
code for HTML, or partial?

Jan: partial, unconventional rendering would be something completely
different that you don't experience when you are hearing the music,
for instance

Greg: the source code for scratch is not something experience either
... I agree, outline would be partial. If you have more examples that
would be useful

Jan: part of the definition lies on top of view.

<Jan> http://www.w3.org/TR/ATAG20/#def-View

Jan: begin with view -- editing views, previews.

Greg: like all the things you do with partial rendering etc. but when
you say rendering doesn't apply to rendering it on the screen...
you're saying a source view of HTML is not rendered at all

<Greg> I think of the verb "render" as meaning "present to the user".

Jan: In atag that's right, I can see uaag saying the source is a type
of rendering though

<Jan> Jan: ...bring in the content rendering defn from ATAG
(conventional, unconvential, etc.) but roll in source views

Jan: there's so much diversity in the ways user agents present things

Greg: outline view would normally put into place over for something
that lacks its own label -- minor point

<Greg> 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.

<Greg> 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?

Greg: some of definitions are not used in document

Jan: property view might be able to go, automatically advancing
viewport important explanation, covers things like automatically
scrolling windows that someone might set up

Greg: no objection as long as it's serving a useful purpose
... instead of defining a term I'm leaning toward just rephrase the
glossary reference that is using it instead of so much

<Jan> http://www.w3.org/TR/ATAG20/#def-Web-Content

Jan: in atag we define the first order terms. Example...

<Greg> 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:".

Greg: 3.2.4, 3.2.2 use term view, also bug in 2.1.7

<Greg> 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...

<Greg> ...*tree control* conventions of the operating environment, not
"standard *text area* conventions for the operating environment".

<Greg> ACTION: Greg to revise 2.1.7 Follow Text Keyboard Conventions
to acknowledge not all view showing text should follow text area
conventions. [recorded in

<trackbot> Created ACTION-728 - Revise 2.1.7 Follow Text Keyboard
Conventions to acknowledge not all view showing text should follow
text area conventions. [on Greg Lowney - due 2012-05-10].

<JAllan> rrsagent assign action-726 to kford
1.5.1 needs decision on whether it is done or not - Action item 723 on Kim

<JAllan> 1.5.1 Global Volume:

<JAllan> The user can independently adjust the volume of all audio
tracks, relative to the global volume level set through operating
environment mechanisms. If the global setting is mute, the user agent
may override a global mute on explicit user request that cautions the
user about the implication. (Level A)

<JAllan> http://www.w3.org/WAI/UA/2012/ED-IMPLEMENTING-UAAG20-20120419/#gl-volume-config

Jim: Single success criteria for 1.5 -- can we mark this done?

Jan: the second sentence is really another criteria

Greg: the reason they are together is otherwise they contradict each other

Jan: should the second one be a note?

Greg: maybe they can be separated. Overall I think that the two
sections are probably correct and clear but it's unfortunate that they
are so lengthy. I think they are right. Do they contradict each other
or not if they are separated?

Jim: rather than creating a new SC I would rather make it a note

Jan: are we going to require for conformance that there be a caution
about the implication?

Greg: let's say operating system I turn volume Low, and Web browser
flash player I explicitly set the volume up high that could be
considered an explicit action requesting it to override. It makes the
global override essentially useless.

Jan: these are not OS guidelines, these are browser guidelines

Greg: if the user agent overrides the mute is that a problem?

Kelly: why is the second sentence here?

Jeanne: think of cell phone, you could put it on mute, but don't want
to not hear reminder

Greg: checkbox don't want to override mute?

Jeanne: don't want a notice every time

Greg: don't want just changing the volume slider to count as the
explicit user action
... doesn't have to be a separate confirmation step like a prompt

Jan: is this an honor system thing where the platform says the user
sets global mute, do what you want?

Greg: I don't think we can make assumptions
... in IER can we make that clear that it doesn't have to be a prompt
because we don't normally want a prompt
... I think it's unfortunate it's too long, but when it's trying to say is right
... it's essentially saying that even though we let the user adjust
the volume independently of the global volume settings but that
doesn't really mean override the mute

Kelly: why for accessibility purposes does the user need this
... this is not you can only do these things, this is the minimum, if
you want to do more, go for it

Greg: deaf coworkers -- computer making noise and not knowing it

Kelly: just as it's written doesn't cover that scenario

Greg: trying to -- second sentence -- user agent should obey global
mute unless the user specifically says otherwise

Kelly: this is all true for all software -- we should delete the
second sentence -- what do people think?

Jim: I'm fine with it, this is a special case that only appeared when
cell phones came up.

Jan: I'd like to see the second sentence removed. Too complicated to
put the two together

agreed that we should delete it

<JAllan> scribe: Kim

Resolution: remove the second sentence from 1.5.1
[End of minutes]

Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 3 May 2012 18:38:10 UTC

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