<scribe> Scribe: JR

<jallan> PP: I found this note interesting in light of our discussion two weeks ago about 3.1 (Toggle background images) and DHTML libraries that use CSS tricks (e.g. background) to draw widgets.

<jallan> Note: The style exception of this checkpoint is based on the assumption that authors have satisfied the requirements of the "Web Content Accessibility Guidelines 1.0" [WCAG10] not to convey information through style alone (e.g., through color alone or style sheets alone).

<jallan> I see how it fits in the 4.4 section. Does it also suggest any changes in 3.1?

(JA: PAsted in Peter's earlier email to list)

<jallan> ja response: JA: Not sure about 3.1, need more information. I think 4.4 may tie into 3.2. Animation can be created with Multimedia, and this may require that in addition to ability not to render the content (3.2), that if the multimedia animation, etc. is rendered then the user should be able to control the speed. there is a note in 3.2 referring to Guideline 4 for add ional requirements

<jallan> "Note: See guideline 4 for additional requirements related to the control of rendered audio, video, and animated images. When these content types are not rendered, they are considered conditional content. See checkpoint 2.3 for information about providing access to conditional content."

(JA: Pasted in Jan's reply email)

(oops JA's email)

<jallan> ja: more, response

<jallan> 4.4 has a normative exclusion

<jallan> 1. The user agent is not required to satisfy this checkpoint for audio and animations whose recognized role is to create a purely stylistic effect. Purely stylistic effects include background sounds, decorative animated images, and effects caused by style sheets.

<jallan> this seems strange to me. the purpose of the audio, animation, etc. should not matter. The user should be able to stop it (3.2) or slow it down (4.4). How is the UA to know what is stylistic and what is real content?

PP: Seemed interesting in light of background being used to draw widgets in style alone

JA: OK makes more sense.
... We should change to say it doesn't matter what the role is, the user still needs control.

JR: Makes sense.

JA: Creating chart will send out soon.

PP's point about animated icons in title bar

JA: Likes JR's second suggestion, calling that icon content.

(http://lists.w3.org/Archives/Public/w3c-wai-ua/2006JulSep/0016.html)

PP: Serves up on every page from that site

JA: btw: in IE it does nothing

<parente> all about site icons: http://en.wikipedia.org/wiki/Favicon

JA: So yes we should count it as contnet

<parente> FYI: IE only shows the icons next to bookmarks

<jallan> need to define the content area to include the title bar, and tabs, etc.

<jallan> the operative definition should be "viewport"

PP: IE seems to have disabled its rendering of these types of icons

<jallan> also need to address control of animations etc. in the address bar (chrome or content?)

JR: Don't have to do any extra work once URL box is considered "viewport"
... It just picks up the viewport reqs

4.3 Configure text colors (P1)

JA: Some sites change the colour of scoll bars
... That could cause access problems if inusufficient contrast.

<jallan> JR: this can be done with CSS, including mouse arrows, and other chrome.

<jallan> JR: the scroll bar functionality is chrome, the change of color etc. (overriding user settings) is a viewport control

JR: Viewport and chrome are combined in these case

<jallan> PP: this is also related to Firefox extensions to change chrome & viewport

JR: Also javascript windows are given size and position by content.
... It is the UA that interprets content and has the responsibility to do it accessibly

PP: Yes, user would benefit from ability to control size and location of those winodws

<jallan> UA/user needs control over positioning and chrome attributes of generated content (javascript pop-ups with no address bar or scroll bar)

<jallan> JR: need abillity to control or over-ride the content rendered by html or script or other method

<jallan> nominally related to 3.4

JR: Goes over msg: http://lists.w3.org/Archives/Public/w3c-wai-ua/2006JulSep/0015.html

All: Generally agree

<jallan> 4.7 techniques address css, but css does not allow for global (os level) control of volume.

<jallan> UA's do not currently render sound natively, they require an external process. only that process can control the volume of the audio rendered by that process.

JA: So with screenreader, user goes there to change volume?

PP: Yes

JA: In HPR can change speech volume, but not sure if it changes other sound volume?

PP: Prob not

JA: Agreed
... Let's top here for today.

top=stop

This is scribe.perl Revision: 1.127  of Date: 2005/08/16 15:12:03  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: JR
Inferring ScribeNick: JR

WARNING: No "Present: ... " found!
Possibly Present: All FYI JR Note PP ja jallan parente
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2006JulSep/0013.html
Got date from IRC log name: 27 Jul 2006
Guessing minutes URL: http://www.w3.org/2006/07/27-ua-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.