W3C logoWeb Accessibility Initiative (WAI) logo Member Events

Face-to-face Meeting -- WAI User Agent Working Group

Chair: Jon Gunderson
Dates:  Friday-Saturday, December 11-12, 1998
Location: Cambridge Mariott, Cambridge, Mass, USA
Time: Friday 8:30am-12:00pm morning session and 1:00pm-5:30pm for afternoon session; Saturday 8:30am-12:00pm morning session

Table of Contents

Conclusions and summary of action items
11 December 1998 minutes (Ian and Daniel)
12 December 1998 minutes (Ian)


Friday, December 11, 1998

8:00 - 8:30 Continental Breakfast

8:30 - 8:40 Preliminaries

8:40 - 9:30 Document organization, definitions and background information including prioritization of techniques and guidelines

Related working draft sections:

9:30 - 10:15 Accessible design principles and practices

Related working draft sections:

10:15 - 10:30 Break

10:30 - 12:00 User control over document rendering

Related working draft sections:

12:00 - 13:00 Lunch

13:00 - 13:45 Alternative document renderings

Related working draft sections:

13:45 - 15:00 Basic navigation and orientation

15:00 - 15:15 Break

15:15 - 17:30 Navigation and orientation for TABLES and FRAMES

Related working draft sections:

18:30 Dinner: Dinner at a local restaurant

Saturday December 12, 1998

8:00 - 8:30 Continental Breakfast

8:30 - 10:00 Navigation and orientation of scripting events and event modifications of document

Related working draft sections:

10:00 - 10:15 Break

10:15 - 11:30 DOM, HTML, CSS1 and CSS2 Compatibility issues

Related working draft sections:

11:30 - 12:00 Statement and review of action items for working draft and working group

12:00 - 13:00 Lunch


Conclusions and summary of action items

Types of user agents

The guidelines should use media types in relationship to techniques, since certain techniques are only useful for visual rendering, while some may only be usefull for aural or Braille rendering. Therefore the guidelines will be more general to the problems and not need to worry about the distinction between assistive technology, mainstream and specialized user agents for the sake of defining user interface techniques.


The conformance statements will be used across all the guidelines. For a user agent to claim conformance they must meet all the priority 1 items for the media types they support and if they want to claim compatibility with assistive technology they must meet all the priority 1 techniques for compatibility. Further discussion is needed to determine if there would be a level 2 or 3 conformance for user agents that implement priority 2 and 3 items in the media types they support. But you cannot claim level 2 or 3 without first doing level 1.

Media Types

The use of media types will allow user agent developers to know what is required for conformance for the media types they support. The initial media types will be taken from the CSS2 specification on media types. There will also be a specification for assistive technology compatibility, so that a user agent that primarily supports one media type can help an assistive technology provide another. For example a user agent like Navigator or Explorer can provide access to their document object model (DOM) for a screen reader to provide an aural rendering of the document.


It is primarily the authors responsibility for ensuring that the script is accessible. There should be features for turning off scripts, and this is generally available in most user agents for security purposes. There was discussion of how the document object model (DOM) could help in providing information about how the document will change or how it has changed before or after a script has executed. There was also discussion on making events device independent and there was a consensus this need to be done by the WAI PF group to educate the DOM and other W3C groups about these issues. There was a question raised whether user agents should try to repair scripts that require the use of the mouse for operation. If the user agent provides a repair feature for the lack of author keyboard support to their script will this provide an out for the author, since the author can say that the user agent will fix their accessibility problems. The repair operation may also not be very functional since the number of events maybe high and the purpose of events cannot be conveyed to users.

Technique 3.6.3 Question raised as to whether this would be sending authors the wrong message about designing for accessibility. Proposal to remove this technique from the guidelines.

Telecon and list organization

The chair would like to propose a more structured approach to the list and telecons:

  1. Issues for the week would be sent to the list on Wednesday after the telecon. They would be labeled in the subject line as ISSUES in all capitol letters.
  2. The group would discuss the issues and priorities and media types associated with those issues during the week on the list.
  3. On or before the following Tuesday the editors and/or working group members would propose new or revised techniques, media types, priorities or examples for resolving the issues. The subject line of all proposals would include PROPOSED in all capitol letters.
  4. The Wednesday telecon would be used for resolving the outstanding issues.
  5. The editors would then post the revised techniques, priorities, media types and/or examples to the guidelines. The URL to the guidelines will be sent to the list with the subject line RESOLUTION in all capitols in the subject line.
  6. Members could review the guideline changes and comment to the list or editors. If additional discussion was needed due to new information or misunderstanding, then it could be posted again for continued discussion on the following week.

This is a three step process to resolving a group of issues a week. The steps are:

ISSUES: Issues sent to the list for discussion for 6 days

PROPOSAL: Proposals sent to the list for discussion at least 1 day before the telecons and will be the basis of discussion in the telecon

RESOLVED: The techniques or examples that will be used for closure on the issue will be posted within 36 hours of the telecon.

Section 3.1 Accessible design principles and practices.

Section 3.2 Ensure the user agent accessibility features are configurable

Section 3.3 Ensure that users can disable features that might interfere with accessibility

Section 3.4 Provide documentation about accessibility features.

Guideline 3.5 Provide summary information about keyboard access

Guideline 4.1 Allow the user to control document styles

Section 5.2 Provide information about document view and point of regard

Section 5.4 Allow sequential keyboard navigation to structures within a document

Guideline 6.2 Use and provide accessible interfaces to other technologies

11 December 1998 minutes

Types of User Agents: mainstream, specialized and assistive technology

WC: Where are companies like Henter-Joyce being represented in the guidelines?

JG: Early on, the concept of independent vs. dependent user agents. What should each type support.

DD: Prefer the distinction between "mainstream" and "specialized". We should put most of our efforts into ensuring the accessibility of mainstream browsers. Specialized user agents already know what to do (it's their bread and butter).

WC: There are inherent conflicts in defining both assistive tech vendors and mainstream browsers as user agents.

DA: Does it make sense to say that the user agent does the rendering and to say that the assistive technology controls the user agent.

DC: Not always about providing the information, but about providing the hooks so that assistive techs can provide the information.

DA: Things that provide access to the rendered information are assistive technologies.

JT: Talking about rendering muddies the waters. I prefer dependent/independent definitions.

IJ: Editors introduced distinction, but haven't developed it sufficiently.

WC: Fix 1.1 (where terms used inconsistently).

DD: To me, Jaws or Webspeak are independent because they have a knowledge of the markup. It's an implementation detail that they don't parse themselves.

JT: I don't think the analogy is quite correct.

CMN: We all know what we mean, and we want to use the concept in the guidelines, but don't have a neatly worded definition yet.

CO: I like Glen's characterization the best. Assistive technology sits on UA and provides access to it. How it does it is irrelevant. Doesn't include PWWebspeak because they can take care of themselves. Any screen reader has to rely on underlying technology that the user may or may not have. PWWebspeak provides that technology (though it uses the IE renderer). But PWWebspeak is a self-contained application.

DD: There are two axes: mainstream vs. specialized and dependent/independent.

JG: How can an agency claim conformance to these guidelines? Perhaps specialized browsers would claim conformance in a different way than mainstream browsers.

CO: This group not formed because we had a lot of complaints about PWWebspeak.

DC: So what is our audience. What are they comfortable with and what do they need?

DD: I agree with both Jon and Chuck. Why don't we say up front that our primary audience is mainstream browsers. Apply, of course, also to specialized user agents.

JT: Guidelines may also be a blueprint for how all types of user agents will communicate (interface).

Therefore important to define who's who and what communication takes place.

DA: Significant different between mainstream browsers and specialized. The guidelines should help UAs be as mainstream as possible.

CMN: Worries me to think that some browsers can be used by everybody and some cannot.

JG: Need to identify classes of UAs so that we can define requirements and responsibilities. Need to formulate appropriate strategies and educate companies.


IJ: Proposes a conformance in which

1) Conformance to three sets (Pri 1/2/3)

DA: I like the proposal that Ian doesn't like. 1) Conformance to all Pri 1 first.

CO: Compliance important 1) Techniques for developers 2) Comply to guidelines Possibly conflicting goals.

Concept of priority (if it were up to me). Either "required" or "recommended" (two priorities rather than three). You either do it or you don't. Give people notice by making a recommendation first, then a requirement later. I also advocate a series of WAI documents (say, every 18 months).

KH: Define conformance in terms of Priority one items. They need to be relevant to industry. The document became unuseful. (Lots of priority ones, wasn't sure why so many Pri 1). Would think that the guidelines would be more of a bell curve: small set Pri 1, lots of Pri 2, fewer Pri 3. Need to be more careful about what we label Pri 1.

<span class="action">Action KH:</span> Send comments to list.</span>

CMN: One problem with the recommendation-to-required track is that this document is meant to address problems now. Document should say "You must do this." Whether now or later, it still must be done. It's important now.

DD: Not just an issue of priorities. A lot list of Priority 1 may mean that the granularity has to change. I agree with CMN in theory. But there is also the market and the implementation has to be part of the loop. Guidelines can't be wildest dreams.

CO: We need techniques to be as specific as possible (lots of techniques ok, useful to developers). Want to be told which attributes of HTML need to be supported. Not just support HTML 4.0. (to CMN:) Technology changes. What may be a problem now may not be a problem in the future. "Don't use tables" may be true now, but in the future, may not be a problem.

IJ: Discussion of distinction between techniques in guidelines document vs. elaboration of techniques in techniques document. Conformance with respect to normative list of techniques as expressed in the guidelines document.

DC: Back to question of dependent/independent. Must describe Pri 1 techniques in terms of "alone" or "in conjunction with" other technologies.

CO: Apply priorities to problems, not solutions. That does not discount the fact that there are better ways than others to accomplish certain things.

DC: Want to avoid reverse engineering to get the job done. Don't want to force impractical solutions.

DA: Hook must be provided, but hook must also be used.

JG: W3C must educate so that developers are aware of these hooks.

WAC: Back to conformance...Have these discussions happened in other groups.

KH: (referring to DA's comment): Native vs. Assistive support. If we provide hooks, we've done our jobs.

GG: Mainstream browsers may not do the right thing for users. Not through fault of their own. Right thing may not be clear.

DD: Some people may not have opportunity to get the technology.

IJ: Economics, bandwidth, platform, ...

CO: Cross-disability benefits of assistive technologies. E.g., multiple table renderings could benefit a wider audience.

JG: Summarizing

1) Who's the audience for the document? Industry developers but also consumer groups (purchasing products that conform to guidelines).

2) Pri 1's are most important for conformance. <span class="resolved">Resolved</span>:

Compliance/Conformance will be to

Priority 1 techniques as expressed in the guidelines document. There is further work to establish what class of user agent must conform to which of those techniques.

Add note: Guidelines are the goals. May be other ways to meet them, but these are the techniques chosen by this WG. In other words, you don't conform to "Accessibility", you conform to the document.

<span class="action">Action editors:</span> Draft exact wording of this conformance statement.

Microsoft agrees with reservations and waits to review pending proposal.

JT (Chair of AU WG): Sounds good.

WAC (Editor of PAGL): Sounds good.

DC: Writing a spec and defining the bar for passing the spec are distinct.

CO (to Denis): Difficult to say "We comply with a technique" since we may not agree with it or think we can do it better. (Comparison iwth Windows Logo guidelines). How do we identify the problems and fix them?

JT: Is the word "technique" appropriate? Perhaps too strongly implies "how". Would "demonstrable outcome" be better?

3) We need to ensure that industry concerns remain in the loop of decision-making.

DC: You can't design for all people. Trying to accomplish something for one group may contradict with the needs of another.





Section 3.1 Accessible design principles and practices.

Technique 3.1.1:

CMN: Change wording to "available through control mechanisms that are not device-dependent."

DA: What if they use third-party assistive techs?

Does this count.

IJ: Recognizes that "all functionalities" is big.

KH: Please underline that access to a button not important, but the functionality offered by the UA is available.

CO: 3.1 Collapse all three.

IJ: 3.1.3 important on its own

IJ: "general principles of design" is vague.

CO: So is "is accessible".

DC: 3.1.2 raises an issue mentioned at the last face-to-face. I'd like to see more about mnemonic or simplistic or logical aids. These techniques are oriented toward visual disabilities and we must also consider cognitive as well. I also think it contradicts 3.1.1

WAC: What worries me about 3.1.1 is that the functionalities must be <strong>readily available</strong>, not just available. Customization is important and I should be able to customize for all functionalities.

DA: Must be functionally accessible as well as just accessible.

KH: I agree in theory with the comment about "readily available" (you don't want to have to go through 5 submenus).

IJ: Users must be able to customize their environment. Also must have access to all functionality. Together, you get what you want.

DA: 3.1.3. Installation procedure must have equivalent accessibility as the application.

CMN: The installation procedure is part of the UA and therefore are subject to the guidelines.

IJ: Is 3.1.2 useful?

DC: Strike it. Covered in 3.1.1

WAC: Part of 3.1.2 is:

1) Use standard platform toolkits (so that screen readers pick up).

2) Accessibility API.

CO: Why should standard platform toolkit be used?

DD: Use platform toolkits (which may be made accessible) for consistency.

WAC (modifying): Whatever tool you use, when you paint text, it should be painted as text, not an image.

JT: Point Wendy making is that there are a lot of things not covered in 3.1.2 (including her point above). Standards will improve accessibility.

CO: Re "how text is drawn". Lowest level: pixels drawn. Higher level - glyph (still an image). Higher level -index to glyph. Higher level - Unicode reference. Always an image. Applications are starting to paint their own image, bypassing OS hooks. Difficult to define "how text is drawn". It's a moving target. This is a very difficult problem: making a user interface and one that's accessible. Not the goal of this group (making content accessible). There are plenty of good references about how to make an interface accessible.

Don't ignore the issue, just don't want to spent a lot of time on this issue. Use platform guidelines.

Let's worry about HTML-specific issues.

CMN: Technique 3.1.2 circular with guideline.

WAC: The principles exist out there and we need to point to them obviously.

IJ: Careful - AU Guidelines will be referring to this document and how to make UA interface accessible.

WAC: We also refer to UAs in the PAGL.

/* Break */

3.4 Provide documentation about accessibility features.

Ian: Comment about "is accessible" again. What does "is accessbile".

WAC: Should this be in a central reference document?

JB: Two things we're planning:

  1. Need for common definitions for all three documents
  2. Need for assistive technology document. (Publish as a W3C NOTE)

DC: In this particular instance, "alternative formats" would be more appropriate than "is accessible".

CMN: I don't agree.

DD: For 3.4 (1, 2, 3). Clarify online "product" documentation.

DA: For many products, the HOWTO install must be accessible before the software itself is installed.

IJ: "is accessible" used rather than refer to specific formats or renderings.

GG: Comments refer to application as well as installation. Define as one unit up front.

CO: This is not an HTML issue, but a general application issue.

HB: Is there a convention that we could live with (e.g., a README file). Appropriate for UAs to depend on a simple text format.

IJ: Both documentation and installation are important entry points and should be in the document.

JB: People frustrated that features not more readily available, even if they exist in a tool. People not very good at finding that information.

CW: Jaws installation - if all you have to do

to install is put your CD in and hit enter, a braille one-liner.

JG: Is there consensus that the techniques in 3.4 cover the issue adequately.

HB: Time element. Installation is a one-time event. Day to day use and accessibility in those scenarios a very different thing.

TW: 3.4.4 is a priority 2. I have concerns about that based on the education project we're working with. Teachers deal with a lot of users, some more savvy than others. This should be a priority 1.

DA: Look at the definitions of Pri 1 vs. Pri 2. If someone shows you the features (even though you don't read the documentation), you can still use the features. Therefore should be a Pri 2.

TW: Problem with educators is that they don't know about these features. And their students don't. Too many people don't know someone who can show them the features.

KH: I agree with Denis. Shouldn't the education role be carried out by the EO WG? Difficult to go into a class of functionalities and ask what meets an accessibility concern. There may be things users use to meet their needs that we might not think of immediately as "accessibility features".

Marja: Following reasoning of "someone else could do it", all the techniques could be Priority 2. Very useful to provide scenarios (e.g., for blind users). Show how features used in combination.

DD: How do we define accessibility feature. Is it a view of the documentation or a separate part of the document.

CMN: To follow up on DD - If your documentation is incomplete, the tool is inaccessible. If complete, but poor quality, doesn't mean inaccessible (just poor). Telling people how to organize their documentation is a hairy issue. Should be Priority 2.

MH: There needs to be some general scenarios about how the tool can be used (whether or not you have a disability). This would be very helpful.

IJ: Suggest integrating accessibility comments throughout documentation, but this would be a recommendation. Realistically, need to provide a separate section that gives a few of the most important entry points.

DC: We shouldn't make the decision about integration or separation. Just to make the information readily available. For 3.4.4 - don't talk about "a section," just readily available.

JB: HTML 4.0 different than a UA. Helpful in HTML 4.0 to sprinkle references. For a UA, however, very useful to have a separate section. Readily available is most important.

DA: Recall definition of Priority 1. Documentation is a "difficult" issue, not impossible.

Guideline 3.5 Provide summary information about keyboard access

How to let people know there are keyboard commands available?

CO: How is 3.5.1 different from 3.4.4?

JG: Former is specific instance of latter.

IJ: Highlight keyboard access since so important.

DA: Providing shortcuts in a menu may not be so useful if you can't get to menu.

IJ: Use OS standard mechanisms.

Guideline 6.2 Use and provide accessible interfaces to other technologies

Use and provide accessible interfaces to other technologies.

CMN: Techniques that begin "Otherwise" feel like they should be collapsed.

IJ: Propose collapsing 6.2.2, 3, 4.

CO: 6.2.1 same as 6.2.5 (or could be made).

CO: 6.2.4 Pet peeve. Define "standard". Propose revise "use operating system-provided interfaces".

DD: Bugs in 6.2.3 wording.

/* Ian: move 6.2.2 to top of list */

Section 3.2 Ensure the user agent accessibility features are configurable

CMN: 3.2.1 and 3.2.2 are potentially in conflict.

What if conventions are inaccessible. Propose mergining into one sensisble technique.

DC: (from on high of soap box): Don't forget cognitive issues.

JG: "mouse-only" to "device-independent".

IJ: "Wheverever possible". Fuzzy. Remove where possible, or enumerate.

DC: Command-line only interface would probably be inaccessible in the broader scheme.

CO: 3.2.1 and 3.2.2 covered in 3.1.

CO: 3.2.3. Microsoft has strong disagreement with priority of that.

CO: 3.2.4. Good idea. Add comment - use the platform-provided mechanism if available.

JB: Don't think 3.2.3 should be Priority 1.

CO: 3.2.5

We have a "restore defaults" button. This doesn't allow you to switch back and forth. Your settings are gone. Not too many applications let you do this.

CMN: Push 3.2.1 and 3.2.2 covered by 3.1. 3.2.3 could be broadened to allow users to configure control of the browser (Pri 1). More general than keyboard access. 3.2.5 is a Pri 3. Won't be strung up for not doing it. Don't see a reason for taking it out.

CO: Does "restore defaults" count for 3.2.5?

CMN: Not entirely.

DA: Microsoft's OS itself lets you do 3.2.5.

CO: Add to 3.2.5 "allow this by logging in as a separate user".

DC: Accessible command keys. 3.2.3 should be Pri 2.

CMN: Allowing reconfiguation of controls seems a general high priority featured.

3.2.5-7 seem candidates to be collapsed.

/* Will discuss with editors off line */

CO: If the developer will do something different, should be a different technique. When pieces are included, push them into guidelines.

DA: If this section of the document is the only place where keyboard controls are discussed, must be priority 1. If discussed elsewhere more specifically, could be pri 2 here.

CO: The ability to configure keyboard access for every application is a worthy feature. Don't think should be priority 1 technique since it doesn't prevent access. Few people yelling at MS "Can't use your browser since I can't remap the keys."

JB: Few cases where inability to remap would make access impossible.

CO: This is Bryan Campbell's big issue. He's a big advocate of the ability to remap and we've discussed extensively.

JB: Chair, how do we proceed to establish the priority level.

<span class="action">Action CMN, CO, KH, DA:</span>

Will reexamine priority of 3.2.3.

Guideline 3.3 Ensure that users can disable features that might interfere with accessibility

IJ: "equivalent textual representation" means "captions". Does this mean "alt text" as well? How to explain what this means to novice readers?

CH: Please clarify whether "equivalent textual representation" also means "alt text". <span class="action">Action editors:</span> Clear this up.

/* CO discusses rendering of dimensions of alt text vs dimensions of image */

WAC 3.3.7: Generalize scripts to programmatic objects and include applets.

CO: In addition to scripts, add techniques related to the loading and execution of embedded objects.

IJ: The definition of "programmatic objects" is important.

GG: Is the browser obligated to tell the server that it's not capable of loading the objects.

DD: Not an issue.

DD: 3.3.9. How is this different from 4.1.14.

IJ: Rendering different from ability to turn on/off.

WAC: Suggest referring to related techniques.


3.3.2: Define "video". A lot done through embedded objects. The UA may not be aware of what's happening. In the case of animations, the UA is aware of this.

(3.3.5, 3.3.6).

3.3.3: UA not available of what's going on in an OBJECT.

MH: I have the same comment. From the user's perspective, animated gifs, etc. all considered "video". I want to turn off "moving stuff".

DC: Goes back to independent vs. dependent UAs. This is a guideline for dependent UAs.

DD: Qualify all of these with "when the user agent knows". Also, if you can turn off embedded content (3.3.7) you accomplish the goal of turning of video effects.

IJ: Proposed: "Where knows" and give details in techniques document (e.g., bgsound).

CMN: Version 2 of IE has menus "Play sounds", "Play video".

WAC: Knowledge about object types through MIME types.

IJ: That goes in the techniques document.

WAC: Propose "blinking, moving, or changing" content.


3.3.4. Does this include alt text? (see above)

3.3.5. Make into "animated and blinking text".

3.3.8. On/Off support for style sheets. Need to separate support for author and user style sheets. Don't think turning off is a priority 1.

3.3.9. This is a rendering issue. Disagree with Priority and placement.

/* Lunch */

HB: Should turn/off be all or nothing? Would like to turn off images generally, but select one

and view it. Add this to intro of section 3.3

DC: That would be a P2.

DA: Features may interfere with "or enhance" (add this) accessibility.

JG: Distinguish user from author style sheets.

WAC: 3.3.8 should be Pri 1 since style sheets can do crazy things.

DC: Not a given who has final control (user or author). Priority 1 is that user have final say.

DD: There are things you cannot change with a user style sheet but that you can turn off, e.g., with a button. E.g., knowing which property I've used to achieve a certain effect may not be obvious.

KH: Did some investigation about this for IE 5 and became clear that this is not a simple problem. E.g., positioning. If I turn off positioning when there are layering effects, what happens?

WAC: IE3 used to allow turn on/off. Netscape allows you to do it. It's possible. Positioning without style sheets means use document order.

IJ: UA shouldn't be responsible for choosing a "next best rendering". Should just render in document order in general case.

KH: What problem is solved by 3.3.9? Assistive techs are solving the problem quite adequately.

JB: A lot of discussion about this at "Closing the Gap". If you are using a screen reader, frame issues may be solved by a screen reader.

WAC: Small screen issue. Learning disability problems as well.

KH: I can understand cognitive issue. Mobility issue solved with navigation. What is it priority 1?

MH: How do access keys interact with different frames? Can't access navbar type frame when focus in a separate frame.

KH: Haven't tried this out.

/* Discussion postponed until CO returns */

Guideline 4.1 Allow the user to control dcoument styles

JG: For 4.1, change to "override author styles and adjust user agent defaults".

DA: If you use that language, would that mean that using the "return to default settings" mean factory defaults?

IJ: "Default values" means the value when the UA starts. Want to be able to change that dynamically, without changing default value. (e.g., Using 27 point font currently for the purposes of a projector, but want 8point when I start up emacs tomorrow in the office). Don't agree that should be "adjust"

UA defaults.

DC: Change by profile?

CNM: Profiles are Pri 3 currently.

4.1.5/6: Change "foreground and background color" to "presentation" (e.g., could use underlining, different voice quality, background music, etc.)

CO: That's a big request. Configurability of the focus rectangle is a big request we get. Can use CSS to accomplish the goal of changing focus.

/* Ian proposes discussing this in the techniques document */

Propose separating techniques for different conditions.

DC: Make media independent. <span class="action">Action Editors:</span> Propose wording that is slightly more general, but doesn't bind UAs for media types not supported. Move specific examples to techniques document.

Re: 4.1.7 Is there a need to control background images? Doesn't the ability to turn on/off background images?

Resolved: Add to 3.3 turn on/off background images and remove from 4.1.

Marja: What's the fallback presentation?

CO: Good question! Rules as I understand them:

1) if no background image, is it set in HTML?

2) if set in CSS, use that.

3) otherwise use OS background color. This may be overridden.

DA: Foreground and background imaging must be independent.

JT: Whatever is done to establish background color, is this covered in the spec?

JG: Yes.

DA: 4.1.8. Users may want to control rate of animation to have access to the information (and not just turn on and off).

CO: I've spoken with several programmers about this. In case of animated GIF, UAs know rate, can scale and stop it. Changing frame rate not a Pri 1. Stopping would be a Pri 1.

DC: Not sure I agree. If showing the action is critical to getting the content, turning off alone doesn't suffice. Information must be conveyed elsewhere.

CO: I agree. Important, but not a must. Billboards, for example that change quickly.

WAC: For ads, I agree. But for information critical to understanding (e.g., how to tie a bow-tie), I think it should be a priority one.

DA: One of the applications of animations is to demonstrate processes. If the object is embedded, the mainstream browser may not need to provide the control. But the functionality must exist.

IJ: Proposed clarification: "When the UA knows how to access the animation rate for an object." (to 4.1.8).

CO: We're working on adding a metric related to "reading rate".

IJ proposal:

2) Add wording that control by rendering agent

3) Add wording that control when UA has access to those particular properties of the object.

1) Is animation rate the only issue?

GH: People will need to start and stop as well.

CO: Pause. Start means from beginning.

HB: Need to be able to backup a little as well.

CO: Proposed user interface for animations: allow tabbing to animations. Use keys to control animation. Also could have vcr-style controls (speed up, slow down).

MH: How do users know what's what and what rules apply to different types of objects.

DC: I think we're going too far down the implementation path. Just allow users to have final control over active media objects.

CO: That's a problem regardless today.

MH: The issue is consistency of controls. Vcr-controls exist for other types of objects.

DC: Is consistency covered by referring to

OS standards?

CO: Possibly. But real-audio may not use the same keys.

<span class="action">Action editors:</span>

Propose wording about (1) per image control [what priority] and global control [what priority] (2) control of rate Pri 1 (3) control of start, stop, pause, continue priority 2 (4) support by rendering agent.

DA: Consistent controls would be a priority 2 concern, not priority 1 in any case.

IJ: Seems outside the scope of this group.

DC: Careful about choosing priorities. Certain groups, but not others, may benefit/suffer due to priority choices. Same issues apply to 4.1.9 as to 4.1.8. Do same issues apply to audio issues?

WAC: For 4.1.12 change "a specific" to "among available tracks."

CMN: The user agent is the one rendering the information.

MH: Yes, but from the user's perspective, you share the same view. Need consistency across media types.

HB: Should the user profile include information about what users never want.

DA: Don't want to have to turn off styles when racing against a seizure.

CO: 4.1.10 will be changed to include "when UA aware of rate".

/* Note: CSS2 may be used to specify volume */

CO: Why is control of volume priority 1?

DA: Use the external volume control.

JB: Not all boxes have a manual volume control.

CO: Shouldn't be a priority 1 since other ways to get at content.

DA: The information would not be available to some groups.

CO: 4.1.12: Should be stricken.

CMN: 4.1.13 Need also to control pitch/tone. This is a CSS2 property as well.

CO: Is supporting "CSS2 aural" a priority 1?

CMN: If you're not using CSS to control them, but still rendering speech, still need to provide a means to control.

DC: Rendering agent is the entity that must be controllable.

CO: Put in 4.1 : Here are the techniques for these things. If you support these things, do them. Otherwise, don't have to.

IJ: We say that in techniques document.

CH: About speech. What does "support" for speech mean? Rendering? Highlighting? Text to speech?

CO: "SAPI" is MS's speech API.

CH: What's the UA in this case?

CO: The browser is not aware of some of the things going on.

MH: I'll speak for the UA... want to be able to speed up, slow down, etc. But need to be clear about recorded speech or synthesized speech. Affects what you need to eo.

CMN: If call it techniques for automatically generated speech, where browser is creating speech, and you want rate, volumn, and pitch control, could put it into techniques for rendered audio. Would provide the clarity.

DA: If talking about recorded speech, that's just audio. Then could do pitch maintenance by audio playback.

MH: with pitch rendering

HB: user profiles may need to pass info to UA.

CO: I would shy away from profiles. Platforms should support these things. These are cross-component issues. Info should be sharable. Proposed: Be able to change the pitch of audio files. What priority?

JT: Would this exclude a group?

JB: Yes, e.g., those hard of hearing.

CO: I recognize its importance. But should it be a priority 1.

WAC: Issue of captions again. Can't assume that they will be provided. Will be helpful and necessary if captions not provided.

DA: Recall that priorities not based on number of people but on locking people at.

JB: You're locking out (1) aging population (vision + hearing loss) and (2) deaf/blind community with range loss. Yes, I believe it locks some groups out.

CO: Each decision will lock out some community. Have to make decision about benefitting greatest number of users as well.

DD: Not all techniques are related to media perception. Some are related to convenience, etc. So not true that all would become Priority 1.

JB: Multimedia is a difficult area for the growing Web. Also an area with not as much advocacy from different groups.

/* Where did 4.1.15 and 4.1.16 come from?

IJ: Paul A. / Scott L */

CO: Several issues

1) Need to control window size based on user need

2) Need to control window position based on user need

Should allow users to turn off automatically spawned windows.

WAC: PAGL says don't use popup windows. But also relies on UAs in the future to warn users.

DD: I consider 4.1.15/4.1.16 to belong more to the section on the user interface. Distinguish that which happens due to HTML from that which happens due to interface (e.g., warning). How do you warn users that a window will pop up? By popping up a window?

CO: This is also a security issue. I want an option that says "prompt me" when new windows are requested.

Tech 1: Turn off entirely

Tech 2: Prompt before.

Windows pop up all the time. UAs have to deal with them. Don't make this a Priority 1 unless we tell vendors of other applications to do this as well.

MK: Any way for UA to know which windows are available?

CMN: No "windows" menu as in Word.

CO: If a new windows popup, a few things happen

a) Programmatic things happen. Screen readers have access to that information.

b) In windows, you get info somewhere in the environment.

GG: I basically agree with CO assuming there's an accessibility aid available. But if not, problem not addressed.

CMN: Propose Pri 2 to 4.1.15/16. Also shift to section three.

CO: Proposed interface: Allow/Don't allow/Prompt. Don't know that we would allow resizable.

CO: Spawning windows part of Javascript environment. What can one do?

CMN: You can disable resize, scroll, etc.

DD: Style guide should say "If you press a button, a dialog will appear". There's a convention in the way menus are displayed to give clues to the user. In HTML, value of "_blank" for the "target" attribute means UA might open a new window.

IJ: Add to techniques document - for target="_blank" UA should inform the user according to the user's customization.

JT: One reason windows are annoying is for people with visual/cognitive limitations. Not necessarily that they don't want them, just that they don't want to be disoriented by them.

JB: These are not usability guidelines. These are accessibility guidelines.

CO: Another real-world example - HTML in email messages. Your browser is started up and disorients as well.

IJ: How much should "usability" and "accessibility" be mixed?

JB: Procurement requirements ususally based on accessibility needs, not usability.

/* Break 3pm */

/* Daniel on minutes */


Table issues: please consult 9 Dec minutes.

JG: Issue is relationship to screen reader (read cross col) Issue also with Table used as layout tool 2 kinds of Table: layout, tabular Different levels of linearization are possible (based on presence of markup or not, kind of table) If not done native in the browser, the assistive technology can use an API to implement it (DOM, DHTML, MSAA). But APIs are not yet standard across browsers

CMN: Can also use CSS positioning

JG: Another concept relevant to table navigation is the point of regard. People want to move up and down, row or col, switch directions, etc.

IJ: Users want cell level access: reformating and navigation are two ways of doing that. That's P1. More navigation improves contextual access (where you are, what column header is relevant). The goal is to define level of table access to prioritize and decide what's done natively or not.

DA: Surrounding information is more than header.

IJ: linearization is not the only way.

DA: linearization is sometimes not approriate (Statistics data for instance)

CO: Keyboard Navigation not the ideal solution

GG: Given the bits on the screen, wants the information in the structure, and the other way

IJ: mapping backward harder (DOM people working on it)

CO: Going from x,y to the element was added in DHTML.

MH: looking at daisy book, it's not just for table, need information of navigation significence.

DA: Navigation long table/document thru element is not adequate, you need to be able to go thru larger chunk.

IJ: lots of navigation schema in the guidelines: hierarchical, thru list, by link, etc. Not eveything is there , but there's lot.

DA: May want to navigate arbitrary element.

MH: in webspeak, we added the ability thru preference to declare which elements are navigable (maybe done thru some style sheet syntax)

JG: one question is what AT wants

DC: Search functionality gives an example of things where the browser

DA: both cell rendering and and cell context information are vital, regardless how it's done.

CO: Some screen readers use API to provide cell by cell access.

IJ: still want to push the most important thing: individual cell information rendered as block, which sounds easy and already supported in the code.

CO: don't want to say it's easy when talking about about new development.

IJ: CSS1 supports block display on all element

CO: maybe already solved

IJ: implementation question, not guidelines

DD: Jaws does table unrolling because IE doesn't do it

JB: how many screen readers do table unrolling

JG: overall, what strategy will solve accessibility the best way: done by browser or done by AT ?

WAC: IE Powertool is an in-between approach that works fine.

JG: similar to running a user script on load that would improve the layout

DA: issue of who would write the scripts

JG: WAI may help?

CH: I favor nagivation and native linearization thru simple user action

GG: like the idea of running script doing linearization that user or AT could fire.

JT: responsibility is shared between browser and AT

CO: maybe have two different techniques: P1 make cell information available, P2: Provide this information natively and possibly navigation as well.

JT: General navigation issue: Keyboard-based selection of anything in an HTML doc that isn't a link/active element?

/* Ian on minutes */

DD: CSS has the 'display' property with 'block' value. From the CSS2 spec: "Conforming HTML user agents may ignore the 'display' property." In the WAI guidelines, we could make it a (Pri 1) requirement. Thus, for table linearization, simple application of CSS.

CO: CSS is always a great way to implement stuff.

CO: Re selection copying. We get this request all the time.

Two ways:

  1. Search for particular text.
  2. Save page as text file, open in text editor to use selection copy.

MH: Word 97 has feature on scrollbar to allow navigation by element.

DA: Point of highlighting text is not to retype it. If you have to copy to find box to highlight and then to copy is pointless.

W3C post-recommendation support of guidelines


1) For WAI in general, there has always been a recognition of the need for promotion and encouragement of implementations based on accessibility improvements. WAI IPO set up for this reason, among others.

2) At W3C in general, movement to improve post-Recommendation follow-up and promotion. Historically, advocacy done by other organizations.

But now W3C management feels the need to support "life after Rec". In particular, the CSS Working Group has pushed hard by creating (or monitoring the creation of) test suites, validation tools, etc. the SYMM WG is in a similar position of monitoring support.

JG: Would WAI be responsible for educating assistive technology developers?

JB: Could be part of WAI's responsibility. Also push to have assistive technologies move towards standardization of interfaces.

CO: Agree that our job would be easier if there were standard interfaces to plug into. What more is needed?

JB: Not everyone uses Windows. To answer Jon's question, yes, could fit into WAI's scope. However, not only WAI's responsibility.

CO: There are similar standards on Unix/Apple systems, but few tools that require it.

JG: Provide code for platforms.

JB: It could be well within WAI's scope to educate developers for important accessibility issues. We don't have the ability or role to enforce. The WG must bear that in mind when writing the guidelines. No guarantee from W3C to enforce.

CO: Lack of participation from other browser manufacturers is indicative of the uphill battle.

DC: Must be as frugal as possible with our priority 1s. We have to be realistic if we want these guidelines implemented.

CO: Discussion on the IG list lately about the PAGL being too much.

HB: Any time a Pri 1 shows up. How do we justify it?

JB: At WAI EO WG meeting this morning, discussion about the "AIEE, it's huge!" thread on the mailing list. Upshot of discussion in that group: the stuff in the PAGL needs to be there. The detail needs to be there. The PAGL WG used to have a checklist and this would be valuable again. We want the content, but need different ways to slice it.

KH: My personal opinion that the guidelines represent a wish list more than industry reality. Would like to reduce number of Priority 1 items. If Pri 1, should a tech be native if affects a large number of users? No one wants "all the stuff" pushed on them, either mainstream browsers or assistive techs.

DC: Laws vs. Regulation. We're doing regulation without defining the basic laws. If we come up with the laws that have to be met ...

JB: I'm concerned about the analogy you're proposing. This is not a legal or regulatory environment. This is a voluntary, consensus-based WG.

IJ: Not "wish list" but expression of accessibility requirements. Industry concerns are built-in by virtue of this discussion.

DA: I agree with DC that we must be frugal with our Priority 1s. But don't want to fall into the trap of "easy vs. hard." The issue is "accessible vs. inaccessible".

JB: I too like "Frugal with Priority 1". We've been talking about screen readers a lot, but there are other disabilities involved that would not have screen readers.

CO: Process questions

1) Yes, this WG should be collecting, validating, and quantifying data. And then working with developers saying "here's the wish list, what's practical?" "If you don't this, you're impacting this set of people." Look at 5.1.3.: Provide user with info about number of tables in a document.

JB: If we create a wish list first and browser manufacturers say what's practical, then browser manufacturers could say "zero", and others will follow.

IJ: Describes how stuff gets in the document. Editors take what shows up on the list. WG is responsible for reviewing the document. Editors do the best they can to glean information and proposed text from the list. And we announce changes at publication.

CO: What's happened is that someone says something and it goes into the document.

DA: As part of the WG, you can say "I don't think that should be a priority 1 technique" and start a dialogue about how people or groups of people might be shut out.

JB: If an item comes in from the list is it automatically a priority 1?

IJ: No. It may be if similar techniques are rated that way.

JB: This process is *not* clean and easy. The result should be a list of requirements that are realistic. Life gets harder towards the end of the document. The WG cannot put off the prioritization of the techniques any longer.

JG: Do we have the techniques that we want?

JG: We've talked about tables and navigation. How would we rewrite guidelines?

IJ: Providing "cell level info" is not enough. It's just part of the document like any other piece.

DC: Is our purpose to provide a developer checklist or to have general working premisses we want followed. I say this because the last draft too ambiguous and we decided we wanted it more broken out since that would make it more quantifiable. Now, broken out, people are protesting it's too specific (or long). This indicates we have opposite and conflicting goals.

JT: We had the same discussion in the AU group. We shouldn't be too draconian to allow vendors to distinguish their products. We should say that this is what we need and why we want it. We will know that you've met this need if this happens.

JG: How do we do this for tables?

CO: Three levels

1) Requirements gathering and prioritization. WG solicits input, does usability studies. Gets input about what problems exist. This WG presents some information that I don't hear from users.

2) Potential solutions and triage of requirements Work with developers here.

3) Actual solutions

This is announced in developer press releases after the product comes out.

I think the WG doesn't work enough at Level 1. The goal of the WG is to produce a document at Level 2.


1) Pri 1: Access to table information

2) Pri 2: Unrolling of tables

IJ: Chuck, why didn't we hear the requirements that you've gleaned.


  1. Lack of time
  2. Discouragement because ideas have been booed down.

In general, chorus of boos when MS makes proposals. E.g., my developer says it's hard to unroll tables in code. A limit to how much arguing one wants to do.

JB: UAGL WG has not been chartered to do usability studies (nor has funding). Also, if you have your own collection of barriers, please share these with the WG. Dave made important points about "back and forth" editing - more specific to less specific. But CO's proposal would slow us down again. I know a lot of people would like to finish quickly. For tomorrow's discussion, people are encouraged to speak to as much detail as possible. I think that CO's comments can still be resolved with some refocusing of the document. I hope they do not reflect complete dissatisfaction with the document.

DA: About the ease/difficulty of unrolling tables. Distinguish barriers to implementation from barriers to accessibility. Unless you're coding, you don't know the barriers to implementation. But we can't say "that's not a problem" if people don't have access.

DC: My one concern about the Priority approach does not take a cross-section of different disability populations. Focuses on the most vocal groups with the largest number of users. That concerns me.

JB: Please note that cross-disability was called for last week. Also for people to examine priority levels. I hope we will also get more participation out of this.

JT: Re linearization of tables - The need is not linearization.

12 December 1998 minutes

8:30 am

Media Types

JG: We're not moving forward enough. I would like to propose the following (conceived with DA last night): Split document into two guidelines those for visual and those for non-visual user agents. How does this affect compliance? Compliance based on what media type a UA supports. Note that one company's compliance should not depend on another company's compliance.

DA: Background - one assumption: niche market browsers only provide the functionality specific to their market. But warning: a UA might say that their niche market is mouse-using visual. Allowing compliance in that area would not be acceptable.

IJ: We already have the pieces in the document. See section 1.1 of the techniques document. Need to integrate that into conformance. But conformance by one company must not depend on conformance or even existence of another company's product. The guidelines must be written so that this is possible.

JB: Denis' background was helpful. But I don't know how conformance implies breaking into several documents.

WAC: 1) We had similar discussions in the PAGL WG. We ended up with two documents, split according to certain dependencies. 2) Agree with need to comply based on media. Several checklists (media split).

MH: The term "UA" is already a tricky term. It includes a lot of devices. Let's define UA clearly, but in one document.

CMN: As RMIT's member until two weeks ago, under the impression that we didn't divide the world based on niche markets, but rather media type dependencies.

DC: I understand the impetus for the proposal, but I have concerns about it. Need to distinguish source from rendering. Of course IE is not a voice browser. But that doesn't mean they can say "we don't know need to support rendering content auditorially since that's not our purpose." Difference between inter and intra media interpretations. All UAs need to facilitate inter media rendering. Other concern: saying assistive technologies can do something doesn't get us further. Users still need to buy the other products to get the job done. I can walk up to any MS machine and can use it thanks to built-in keyboard support and accessibility.

HB: If we fragment this document into special case needs, we must do the interface definitions very carefully.

MH: I agree with DC and HB. Also a question for MS - where will my handheld computer fall? /* IJ shows how media types are used in the CSS 2 specification: http://www.w3.org/TR/REC-CSS2 */

WC: If we split into two documents, how will compliance be measured? Who will I claim compliance to?

CMN: To follow up: we should not split the document.

Consensus: The WG will produce one guidelines document (with a techniques supplement).

DD: Media conformance (as in CSS) is a more general solution than a visual/non-visual split. It wouldn't be practical to split into N documents for N media types. It's my opinion that it's more important to make sure mainstream UAs are compliant rather than focusing on specialized UAs

MH: I agree with Ian's model as shown in CSS2. How does co-dependency work? What if a UA and another in conjunction form a "fully compliant" UA?

DA: Nice if we can use divisions across documents (i.e., with CSS2).

KH: I like the media type split idea. If we claim to support a given media type, we implement natively. Otherwise we make the information available through an interface.

JB (to MH's comment): Danger in assistive techs "sleeping with" mainstream UAs in terms of compliance. On the one hand, ensures access. But limits competitive choice.

MH: Important point is that it's not vendor-specific. If we do this through DOM, I work immediately with another UA that employs that interface.

DC: Ensure media separation. DD (to MH): I can't map DOM onto a media-dependency. I can't force a handheld device to comply with DOM since there's no way to plug it in. Consider a small device that does visual but that is too small to support the DOM.

CMN: Here's where it does apply: In Australia, there are information kiosks everywhere. There is no way to plug into that browser.

DD: In addition to media independence, an attribute such as "I claim to export". DA: If I'm a device that doesn't do, e.g., video, how do I support video? Must I support alternative representations of it? JG (Summarizing) 1) One document 2) Media type split 3) How to handle unsupported media 4) What happens when a UA can't communicate with others.

IJ: We're stuck on table linearization because of dependencies. When each UA is independent for what it does (w.r.t. a media type) and provides info through an interface for what it doesn't, we are all happy. But the case of screen readers shows another dependency: the screen reader depends not on the interface but the visual rendering.

JG: We want long-term solutions, not quick fixes. Resolved: Make full conformance with DOM level 1 a priority one technique for UAs that export HTML or XML information.

KH: We do some things with MSAA, others with DOM.

Action editors:

1) Propose conformance text to the mailing list

2) Propose media type text to the mailing list

/* Break */ 10am

GG: Good idea to specify the level of functionality expected (by media type). Standards should not say how something will be implemented.

IJ: Rationales should describe goal. But conformance is to a specific list. Conformance is not to "accessibility" in general.

/* End of conformance and media types discussion */

Section 5.2: Provide information about document view and point or regard

5.2 Point of regard 5.2.1 Is this a priority 1?

IJ: 5.2.1. For UAs that support multiple views.

DA: Think should be a priority 2.

DD: Think should be a priority 2.

GG: Think should be a priority 2, in particular since some things have to go (i.e., from Priority 1s). Jaws used to not provide frame information and people survived. Now they do (for IE).

CMN: How does this extend to having multiple browser processes.

GG: Most screen readers will typically tell you as you move from window to window and process to process. Typically title bar info will tell you where you are.

IJ: Is there some class of disability for which browsing would be impossible?

CMN: May be an issue for some people with cognitive impairments.

DA: May be some individuals, but can't say whether would be impossible for all people to use.

WAC: Implication for PAGL. We have a technique that it's a priority 1 to name all frames. Does this change our requirement?

DC: Will priority levels be evaluated during cross-disability review?

JB: Yes. Comments on guidelines will be sent to the appropriate list. Senders won't do further advocacy or become WG participants. 5.2.2

CMN: Priority 1, applies to all media types that are dynamic.

IJ: In the CSS spec, we have the media group "interactive". Thus, printers don't have to allow highlighting.

GG: Why is selection a priority 1?

CO: In visual realm, we use standard system colors and attributes for selection.

IJ: Selection required for *all* users.

DC: Do we want to add "programmatically" to all of these.

CO: Separate "rendering" (e.g., of focus) from "access to" (programmatically).

GG: There are cases when you can't get at the selection other than how it's rendered.

DA: If you provide a selection mechanism, user must know how it is selected.

IJ: I think highlighting is Pri 1 since everyone in this room needs a highlighting mechanism.

CO: Currently, there's no means in the Windows OS to do selection (programmatically). Selection color should be removed (or color changed) when you switch windows. Resolved: 5.2.2 Priority 1. If UA supports selection mechanism. Media: all.

CO: Add to "identifying" : "through standard interfaces where available". Worried about wiggle room if a UA implements rendering but not through a standard OS interface.

DA: Don't forget sound highlighting. DC: I think wiggle room is ok. 5.2.3 Is this the same issue? CO: Focus is more important than selection, but should be treated the same.

CO: Editorial comment - keep wording similar between selection and focus for all pertinent techniques. 5.2.4

CMN: I suggest that this be moved to Pri 2, with caveat that cognitive disability groups might respond that this deserves Pri 1.

DC: I second this. KH: I think there are two scenarios: 1) Moving viewport to follow focus. I think Pri 1 to move the viewport to follow the focus. 2) Moving focus to follow the viewport. I think Pri 2 to move the focus to follow the viewport. This is a good feature. Should be available, user should be able to turn on/off. CMN: Propose Pri 2 for case 1, Pri 3 for case 2.

DC: We shouldn't be delving into User Interface issues so much.

CO: Important to ensure that focus, selection, etc. be in the viewport. Think that 5.2.4 should read that the user's POR be within the viewport. CMN: Example - using emacsspeak. Wouldn't want it to read what's a page and a half away from the viewport.

DC: Don't think guidelines should discuss UI. The focus can be outside of the viewport, but if it changes, the viewport must follow it.

WAC: If I scroll down and focus outside of viewport, but start tabbing, should the viewport move to the focus earlier in the document or the focus move into the viewport?

IJ: Propose two techniques: 1) Priority 1 when focus changes, must then be in the viewport. 2) Whether you move the viewport to meet the focus or the focus to meet the current viewport's location is not Priority 1.

DC: Focus and tab order could be different. If you search text to move to a point in the text, your focus doesn't change, but your selection does.

IJ: Propose that when the selection changes, it should be in the viewport afterwards. WAC: I'm confused.

/* Ian tries to explain */

Resolved: Priority 1 when focus or selection changes, afterward the focus or selection must be in the viewport.

WAC: Proposal: I think moving the focus to follow the viewport should be at least a Priority 2 functionality.

CMN: Should be a togglable feature.

JG: Add a navigation command to move the focus to the first focusable place in the viewport if one exists.

IJ: For any "thing" you want to navigate to, navigate to the next logical "thing" or navigate to the next "thing" in the viewport.

CO: But how does this interact with tabindex?

IJ: Good question.

/* CMN Proposes we push this to mailing list and move on to script navigation */

5.3 Note: MS would like to get feedback on keyboard models.

CO: the Web TV-style model (four buttons to get anywhere on the page). MS also working on keyboard navigation to non-document parts of a UI. After the meeting, we would like to solicit input from people interested in this. 5.3.1


JG: From last meeting, sentiment that scripts are not inherently accessible or inaccessible. But when a script creates a user interface, it should follow the UA guidelines related to interfaces.

DA: This means a script might be considered a UA.

JG: There are both device-dependent and device-independent events (e.g., mouse-down, etc.).

/* Editor's note: sort techniques in section 5.3 */

DC: There's a difference between server-side and client-side scripting. We're concerned about changes to the UA output.

CMN: I have a question about triggering events. The device-independent part is covered by 3.1.1 (allow device independence). I would like this group to formally take this to the P&F WG and examine the event model and take to HTML/DOM WGs.

JB: It's already in that WG. DD: 5.3.1: We need to say that doing this through an API is ok.

CO: IE currently and will in the future support 5.3.1. User can say disable/enable/prompt before scripts are executed.

IJ: Add "security reasons" to rationale section about alerts before script is executed.

DD: Divide "ability to alert" from "user wants to be alerted".

CNM: Propose to drop 5.3.1 (since, e.g., some scripts don't cause change). Boost 5.3.2 up in priority and say "when changes occur, there could be accessibility problems".

CO: Let's keep 5.3.1. It's a stop-gap (and MS already does it!) It's a useful technique.

GG: From a usability standpoint, it's not clear how valuable it is to know something before every script is run. I may want to disable or enable all scripts. But when a change occurs, I want to know. But impossible to know what the change is.

DA: Gregg Vanderheiden has an example of a page with a spinning globe. If the globe is decorative, who cares. But if it's a map with links, knowing that and providing alternatives is crucial. IJ and WAC talk about interdependence of PAGL and UAGL on this issue. Not sure where burden should fall.

DC: 5.3.2 has to be priority 2 if not level 1.

WAC: I agree with DC that 5.3.2 should be Pri 1. WAC: Notification based on execution and timing of execution configurable. IJ proposes: 1) UA should allow turn on/off scripts (3.3.8) 2) Author should provide alt information for important scripts describing what a script will do (e.g., cost money, change environment). Talk to PAGL WG and HTML WG about this. 3) UA must provide access to that information.

DC: Difference between notification and instant rendering.

CO: MS is coming from a background of documents that suddenly got behavior. Can we get a "title" attribute on SCRIPT element?

/* "title" is not on SCRIPT element in HTML 4.0 */

CO: Lots of scripts are just useful to programmer. In other languages, you wouldn't want this, why for HTML. CMN: Yes, we want document about what code does. Specifically for embedded applets, PAGL requires that that information be available through other means. Also suggests that in the content of the page, explain what important scripts will do.

DA: I only want to know about *significant* changes. Just like a button on a user interface.

GG: There seems to be two kinds of scripts 1) One makes underlining page look smarter. You don't care about that type of script. This type we don't care about. 2) Another script makes the page behave in an unexpected fashion that might cause a screen reader to miss something. Need to provide a description (e.g., on the status bar). The average community is not striving for this functionality.

KH: The UA doesn't know what a script will do. The author knows what the script is expected to do. IJ: There's (unfortunately) no longdesc on SCRIPT, which seems to be the missing piece.

DC: To provide alt content for scripts: 1) Use NOSCRIPT 2) Use "alt" with APPLET.

DD: A script can generate html that is included in the document that explains what the script does.

IJ: Good idea. CMN: We're not asking UA to figure out script semantics. We're asking Authors to provide a description.

CO: We should expect that script authors not do unexpected things. Or we expect authors to document them.

DD: Proposes: 1) Users must be able to turn on/off scripts (Pri 1) 2) When scripting changes the document output (which the UA knows after the fact), the UA should alert, through an interface, that the document has changed. Pri 1.

CO: There is work under way in msaa to inform of changes in document model. DD: Also being discussed by DOM WG.

CMN: Note also that this is covered by the guideline to use W3C specs when available/pertinent. The rest is not up to the UA to handle.========What to expect in near future:

1) No document before end of year (due to editor commitments)

2) Will keep issues list up to date.

3) Proposals from editors will be sent to mailing list before being integrated into document. [Some Subject trickery like "Proposed: ..."]

JB: I've seen other WGs do this (face-to-face and teleconfs): issues will have been posted, discussion on email, hammered into a proposal, then consensus is declared and the issue considered "closed" unless new information is presented.

IJ: Chair is also resonsible for recording minority opinions.

/* Lunch */

Should we allow users to navigate elements with scripts and synthesize those events (trigger them through other means)? Need "onactivate". (Not in HTML 4.0).

Guideline 5.4 Allow sequential keyboard navigation to structures within a document

GG: This should be a DOM issue and adaptive technology vendor issue. 5.4.4: Navigation among elements with event handlers.

DD: Do through the DOM (interface).

CMN: I don't think that *navigation* of these is not priority 1 (should be pri 2). And the triggering is covered by 3.1.1.

KH: I don't think that any of 5.4.1/2/3/4 should be priority 1. I think navigation among active elements is priority 1.

IJ: Pri 2 to navigate among specific classes of objects.

KH: Another concern - conformance. In IE currently, we don't provide keyboard access to elements unless they are links or form controls. E.g., can't navigate to headers with associated scripts. Want to ensure that techniques written so that missing one functionality doesn't mean conformance broken for three techniques.

CMN: But if you don't give access to headers with "onmouseover", you violate more than one technique.

WAC: Scripts are to browser what browser is to OS (with inheritance).

CMN: Scripts need repair strategy from UA. We would all benefit from a proper event model.

DC: I concur with my colleague from Australia that 3.3.1 covers this whole discussion.

/* Discussion of synthesis of event triggering */

CO: Problem is not identifying the events but identifying the keyboard model for activating them. (Navigating from element with event to element with event).

IJ: Not hard to insert events into the list of things that can have focus. Then right click to activate a particular event.

CO: In theory, not hard. But would be ugly. I think this should be handled by P&F.;

DC: I hear CO saying that if it's ugly then we shouldn't put it in the guidelines.

CO: I *do* want to do this. It's political issue, to. If you provide a "crutch" (for keyboard access), the result could be lazy authors. "We don't have to provide keyboard access since the UA does it." JG: Proposed 5.4.4. Do we provide a repair strategy for this case?

CO: I think the technique should be in there, should discuss the priority.

CMN: Don't think we need a repair strategy. The solution is ugly. The more specific we make our solutions, the more we lock ourselves into those solutions. My favorite 3.1.1 covers us and we shouldn't discuss implementations. Let P&F fix this properly. The more we specify the repair strategy, the more we delay creating a real solution. WAC: If a priority 1, you would navigate to a lot of elements that aren't really that interesting.

DC: I read 3.1.1 to mean program commands generated output.

JG: Leave in 5.4.4 as Priority 2 for now.

CO: Propose to move to issues list.

JG: How do we deal with issues on the telecons and e-mail list?

Telecons and e-mail list for resolving issues

HB: In XML, we handled about 10 issues a week.

JB: Need to take time at end of a meeting to summarize "where we are". Need telecons to discuss resolutions.

CO: Need to translate issue to guideline. I think that's the Chair's job. Prioritizing them is another process.

KH: We need more organization of the list and the telecons so people know what is issue is being resolved

JG: I will propose a new telecon and list process to make it more structured for resolving issues on the list and telecons

Copyright © 1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.