Minutes from 10 December 1999 UAGL ftf at IBM (Austin, TX, USA)



Issue 114 (continued)

IJ: I have some concerns about deleting 5.4

JA: No techniques currently.

JT: Covered by 5.3

Issue 120

The UAGL should pay more attention to UI accessibility.

How do the ATAG 7.1 checkpoint (Use all applicable operating system and accessibility standards and conventions) and 5.3 (refer to yesterday's discussion) related?

JT: Why are they are any different?

GR: Installation, updates, UI all must be accessible.

JT: What else is there besides the UI for accessibility?


JG, GR, JT find the relative priority to non-W3C specs overly ambiguous.

Proposed: Make 10.5 (avoid keyboard conflicts) a technique of 5.8.

GR: I oppose since this is an important special case. I want to bring this to the attention of AT developers as well.

JT: But the special case is covered in second half of 5.8

JA: Looks like 10.5 is a special case of 10.4

DP: I think we should keep 10.5

RS: I agree that it's important to highlight the issues. But try to avoid pointing to 10 different places in the document.

/* DB joins */

RS Proposed: Merge 5.8, 10.5, 10.4. in order to put the keyboard-related checkpoints together.

GR: I worry that we will over tersify. The ATAG Guidelines have experienced problems in PR review due to ambiguities that have crept in during tersification.

DB: I think that keyboard accessibility is important and that it's a good idea to put it in one place.

/* Jon brings us back to the issue... */

JG: Do we feel we have sufficient coverage of the UI?

/* IJ reviews areas of the spec that have to do with UI */

IJ: Is "notification" (to the user) part of the UI?

DA: This is one of those things that bridges both content and UI.

IJ: In almost every Guideline, there are UI-related checkpoints.

Resolved: No changes since:

Issue 121

Consider reordering/grouping the checkpoints/Guidelines (e.g., accessible content/accessible UI)

Resolved: It's sufficient to identify UI/Content checkpoints within current Guidelines.

Issue 122

Proposed checkpoint related to input focus on controls

Resolved yesterday in issue 128.

IJ: Is there a notion of "selection" at the UI level?

JT: In lists.

RS: The resolution yesterday "How UI focus is initially set on a control is an OS, not UA, issue." isn't quite right. The application also has control over the focus.

/* Ian demonstrates window manager behavior that controls active window */

GR: Say I'm typing an email message and another window steals focus. My action of typing, without my knowledge, is being taken by another application. Dynamic changes, that can be useful for some users, can be detrimental to others.

SW: Most of the time, when a window first becomes active, the UA can choose to set focus where it wants.

Observation: Focus may be set by UA or OS or Window manager.

JG: Two questions it would seem:

  1. Does the user know that the new window has spawned?
  2. Does the user know where the focus is?

JG: Naive users won't understand focus issues.

RS: (Reading from Java Guidelines about Java swing/focus)

DA: When a window seizes focus, the user has to know that's happened.

Proposed KB:

WAC: What's the role of the AT in this? What should the AT be doing? If the changes are focus are provided programmatically, the AT can pick them up.

SW: The problem mentioned by GR is one that everyone shares. Normally, for very important input, we steal the focus and prompt for confirmation. The confirmation can help prevent errors.

DA: For GR's issue, one thing we discussed yesterday was

/* IJ notes that 4.15 should cross-reference 9.1 */

DP: The AT can play a role (it may make choices about what to do). Some may not be configurable by the user; would be good to add.

WAC: Are we documenting somewhere these broken issues? It would be good to track the usability issues being raised. We should get that information to the appropriate bodies (through EO). Or, this may be a follow-up activity; work with AT developers, etc. This sounds like a usability issue to me. I think we should design the UAGL in a way that does not try to fix all the AT problems.

RS: The problem isn't as simple as we think: there are popup windows, tool tips, bubble help, and more. The only concrete way to identify the active window is to give it focus. There may even be some objects not in the window tree. I don't think this is a usability issue for the AT. The problem is that there's no standard for addressing this.

DB: I agree with WAC that we need to document, but we shouldn't try to solve all these problems in the guidelines.

WAC: If the information isn't getting to the ATs, then we need to get it to them. That's what the checkpoint on programmatic access is about.

/* MQ joins */

Proposed IJ:

JT: I think point two is ludicrous. I think that it doesn't make sense to say "Don't shift focus to new window" since otherwise ATs can't cope with it.

WAC: The focus is a technique for 9.1 (Provide information about user agent-initiated content and viewport changes through the user interface and through APIs.)

JA: My thought is that it's ok for a popup to get focus. But can the window (not the button) get the focus?

WAC: That's a technique: where's the best place to put focus. WAC notes that we don't have a checkpoint about usability.

WAC: Though focus may be a technique for notification, the ATs should moreover have information about creation events.

RS: You can't track window creation/deletion. You also need to know about views that are not supported to have the focus; windows are created and destroyed all the time. You don't want to use creation/deletion events.


IJ: Why point 2? Why can't the UA tell you, e.g., in the status bar. You could be notified with a beep or in the status bar.


JG: Unresolved. We need developer input to know how this would be implemented.

RS: Even if current focus doesn't shift to a new viewport, if that viewport obscures the one you're working in, then ATs that rely on the offscreen model will have the current viewport's text obscured.

Resolved: Issue 122 is resolved with a note in 5.5

New issue: User control of current focus change and notification.

Action JG: Add to issues list.

Action GR, DP: Send to the list techniques for how this will work. In particular, how this will work with ATs.

Issue 123

Proposed checkpoint to use standard UI components for the interface.

Resolved: The new 5.3 covers this request.

Add Earl's text to techniques (or prose):

a) use the platform's standard UI components whenever possible and ensure that custom components provide equivalent accessibility information as standard UI components in the same programmatic way or b) ensure UI components not based on a platform's standard UI toolkit provide information and events equivalent to that found in currently available accessibility APIs (i.e. JAAPI and MSAA).

Issue 124

Should the Guidelines reference MSAA and JAAPI?

RS: The DOM is platform and language-independent. Thus seems acceptable in the Guidelines references while the others are not.

IJ: Why are HTML, CSS, there? DOM yes (it's referenced from a checkpoint).


Issue 113

Deletion of Guideline 2: Support the Keyboard

JT: I'm sad to see the Guideline go, but I think it already stands out adequately in a number of questions.

RS: I think we spent a lot of resources on this issue and that it's resolved.

DA: When we were discussing

Resolved: Add a section to the checklist on the keyboard. Note that there is already a section on UI checkpoint.

Issue 147

Need to review priority and wording of 5.8

JT: I agree with GV's concern. There are parts of 5.8 that are priority 1 (e.g., high-contrast settings).

JG: Note that the priority of this checkpoint is 2 because this is about "using conventions". If accessibility is achievable in other ways, that's ok.

GR: My concern is that too much is being compacted into a single checkpoint. I think that installation and updates needs to be P1 (if you can't install it, you can't use it).

IJ: But "installation must be accessible" breaks down into existing checkpoints.

Action GR: Write a technique on accessible installation.

/* Scott Luebking joins */

KB: Should we remove "installation and documentation" from this note to not make that seem P2?

DB: I'm not sure that the Windows installation is every bit accessible (e.g., the identification code on the back of the CD jewel case).

GR: This came up in AG last call review. The WG decided that ATAG 7.1 covered keyboard access, online support, installation, etc.

DP: Maybe mention installation in G10 about configuration

DA: I think 1.1 (every functionality) covers it. Extend 1.1 to include installation.

RS: I would say that the installation program must be accessible per these guidelines.

MQ: I have some reservations about not highlighting installation more.


Issue 150

Do APIs apply when the software is accessible on its own?

DA: In yesterday's discussion, we discussed preferences (cross-platform, OS-specific, your own accessible approach).

DA: You can be accessible maybe, but not conform.

RS: If I built in assistive technology, does that suffice?

DP: I think that in our current context and what the guidelines attempt to do, the answer is no: you have to include communication.

GR: Specialized tools may be accessible to some users, but when we refer to accessibility in this document, we include communication with the user's preferred AT.


Issue 154

Expose class names to the user.

GR: This allows the user to design styles to override author styles based on classes.


Action Ian: Add to techniques.

Issue 165

Add information about system level flags to 5.2.


/* Lunch 12:05 */

Guideline 6

Issue 111

Proposal to make Checkpoint 6.1 have a relative priority

Eric Hansen, IJ, CMN support.

GR: We're talking about specifications; pieces that are part and parcel of the specification.

WAC: I think that if this not a P1 checkpoint, it will be detrimental to WCAG since if no UAs implement the P3 checkpoints, no authors will use them. Having a relative priority means that a UA could choose to only implement the P1 checkpoints, which is also detrimental.

DP: Relativity raises lots of issues that we shouldn't enter into. It will already be hard enough for developers to gauge conformance.

JA: I think it should be P1 since one of the biggest issues we have today is inconsistent implementation of standards. If UAs implemented the standards, we wouldn't be having the issues we're having today.

GR: It's apples and oranges with ATAG. The practices we recommend are useless if the features are not implemented.

RS: Leave a P1.

JT: Leave a P1.

DB: Leave a P1.

PJ: Leave as P1.

IJ: I'll be quiet for now.

Resolved: Leave a P1.

Issue 157

Correct reference to XSL in checkpoint 6.2 since only a Working Draft.


Action Ian: Propose a technique for using XSL to transform content.

Guideline 7

Issue 160

Delete checkpoints 7.3 and 8.2 (related to tables) since too vague

IJ: These were generalized to include browsers when we decided not to focus on ATs. The result is we have checkpoints that don't make sense to developers.

JT: 7.3 as written doesn't make sense.

DA: Recall that linearization is not sufficient; you can't destroy the relationships among cells.

IJ: The reason this checkpoint has become weak is that the way a browser would satisfy the checkpoint is by doing nothing special. UA developers were confused because they didn't have to do anything special to satisfy the checkpoint visually.

GR: One area where UA developers have traditionally failed is in navigation. So ATs have had to pick up the slack. This belongs properly in the purview of the UA. I don't see how you can divorce navigation from the browser.


DP: This is just like tabbing through a Web page. This checkpoint draws attention to tables used properly as data tables.

WAC: Until there is support for CSS2, people will continue to use tables for layout, and people should be able to navigate tables used for data or layout. You need access to info on a cell by cell basis.

DB: How will it be possible to navigate through tables?

GR: That's just a technique issue. Consider the Opera "form mode". You use one key to activate the mode, the same navigation keys to do cell navigation.

DA: Every time we have the table navigation discussion, the issue of tables for layout arises.

IJ: The WG has already been here and resolved that the most important pieces were access to content and to context. Navigation was only a technique. Beware of reintroducing navigation as a requirement again...

RS: The UA doesn't need to support navigation because the AT will have to reproduce the effort anyway. Even if the UA provides the feature, the AT has to go in and get the information (e.g., the DOM).

DB: Does the current checkpoint have to be a P1? If it's not impossible to get information out of the table, this shouldn't be a P1.

JT: I'm not concerned about 7.3 re: layout tables. I think that it's not the browser's responsibility to support table navigation.

GR: It's not an either-or proposition - you need both.

IJ: Why is the navigation a P1?

GR: If it's left up to the AT vendors, you'll have 10 different implementations. When you're navigating (in the world) as a blind person, you learn "O and M: Orientation and Mobility".

IJ: What are the criteria for determining responsibility of UA or AT? I don't understand sometimes where people are drawing the line between "my preferred AT should do this" and "this is the UA's responsibility".

IJ: Remember also that we used to have other checkpoints for structure navigation (e.g., "chunks") and they were subsumed by a single structured navigation checkpoint and details / approaches in the techniques document.

IJ: I think it would be useful to go to the Director with a well-documented set of criteria about what is the UA's responsibility and what is the AT's responsibility.

JG: We're not providing P1 access to other non-active elements. Part of the reason we're requiring the DOM is so that ATs have access to this information.

DA: I would say that Ian's comment about "you don't need a checkpoint for tables" says why you do: it's the only 2-dimensional structure.

IJ: The implementation issue is negligible. All the information is available through the DOM and it's a two-line perl script to walk it to find out what the next table cell is.

GR: There are things that properly belong in the UA or in the AT. Why have the keyboard checkpoint if everything is available through the DOM.

JT: DP keeps bringing up voice browsers and small screens. That's a non-issue because if they want it they will implement it. It doesn't make sense to implement the table navigation in a graphical browser.

DB: This might stay in the guidelines as a P2 checkpoint.

RS: As an AT developer, even if I had access to a focused table cell: to provide this information via an offscreen model is a mistake (text will be clipped, etc.). So, to get the information in a contiguous format, you use the DOM. If you are walking the DOM, then this lies within the AT and why put the burden on the UA. From a realistic standpoint, there's no reason to put it in the UA. A table is as important as a DIV, a list, or any other piece of contextual information. I agree that you need to be able to navigate tables, but this should be the AT's responsiblity.

DP: We already have a checkpoint to make content accessible. I think we need to keep this checkpoint and keep it as a P1.

WAC: I suspect that one reason that ATs have not implemented the features that we're discussing is that they can't: e.g., they don't have full access to the DOM. That emphasizes the need for good support of the DOM.

DA: I think that it's clear from the heat of the discussion that table navigation is not a solved problem. If the ATs can't solve the problem even with the DOM, then UAs need to do more.

GR: Three things I don't understand:

  1. Why bring up the offscreen model?
  2. How can you say that it's ok to put the burden of structured navigation on the UA but for ATs, do it through the DOM

WAC: We have techniques on how to navigate tables. Mark Novak has a tool called "Help DB" that uses the DOM to navigate tables and works with IE.

JG: How do you give focus to the table?

WAC: You double click on the table to give it focus. Or, you can request a list of tables and then go to the table that you are interested in.

RS: Once you get into a table, you still need the DOM since half of the information may not be available on the screen. You may have nested tables. Being able to navigate from element to element, you'll be lost without the contextual information provided by the DOM. If you give people inaccurate information, that's as bad as providing no information at all. The AT will have to get into the DOM in any case.

DP: Why is sequential access of active elements different than table navigation. In the near future you will see improvement in AT navigation of tables.

WAC: I suggest that we leave this issue open and that people look at current implementations:

  1. HelpDB
  2. Emacspeak (in the WWW browser).

IJ: This is a political, not technical issue. Why tables?

GR: Here's why the UA should do it: single-browser intranets - you only have one choice in what you can use. Leaving responsibilities to the AT alone is not the way to provide functionalities?

IJ: Why not nested lists?

GR: Tables can be vastly more complex. I would prefer this be done by UAs even if ATs do it.

DB: Still think it could stay as a P2.

RS: I think that if you say that table navigation is P1, then all structural navigation should be P1. I agree with Ian that nested lists are dreadful.

IJ: I just need to hear the WG say "Tables are that important, period." I would accept table navigation as an important special case, but I haven't heard technical reasons why it is. But the WG could simply declare "they are that important."

KB: I agree.

GR: Not only does the WG have to say "this is important", but the WG must ask real users what's the hardest for them to use. I think that one of the reasons it's been a hot topic for so long is that it's so extremely important.

DA: The reason I would say that tables are "that important" is the fact that they are two dimensional (or more). With true tabular data, the information is in the relationships is lost unless I have navigation. You need to know trends in tables; you need sequential access to get the information out of the table. That's why it's a special case.

Proposed WAC:

RS: It might be easier to create a general structured navigation model instead of having to pick and choose what to do.

DB: I'd oppose 7.7 as a P1.

Rabi: Yes, consistency in navigation would make it easier on developers. It would be awkward to just do tables. If you've written the code for tables, why not do it for lists.

Objections to 7.7 as P1 with tables: DB, JT, RS

Support for 7.7 as P1 with tables: DA, GR, WAC, DP, JA, KB

IJ: Proposed

WAC: If we make this a P2, then we have to change something within the priorities. It's impossible for complex tables to get the information.

JT: With navigation, it's equally impossible. Consider a large TV listing. Just being able to navigate cells doesn't make it possible to get the information.

Rabi: To navigate horz and vert is easy. But to get meaning out is very difficult.

IJ: I think for very large tables, direct access to cells is also required (notably for users with physical impairments). So why would sequential access to table cells suffice.

DA: Like many of the other issues, the checkpoint doesn't specify how, just what. The user has to be able to navigate tables, and the UA has to make the information available to ATs.

JT: Are you suggesting that "Allow the user to navigate" is satisfied by by the DOM if the DOm has that functionality?

JT: Navigation doesn't guarantee understanding of tables. Checkpoint 8.1 doesn't help. If you render a table graphically with headers in bold, etc. you satisfy 8.1

IJ: the problem is that 7.7 and 8.1 were designed to allow UAs to satisfy them already. Since these Guidelines are for graphical desktop browsers primarily, then they are kind of useless; the requirement needs to be captured, but perhaps not within the scope of this document.

Rabi: There's almost a requirement that every browser written analyze the syntax of the table and surrounding context. The solution would have to work in any situation (not just 50% of the time, whatever authors write). Can you guarantee 100% solution with weird nested and complex tables? You need to state whether the functionality would apply to absolutely all tables or just simple ones...

WAC: HelpDB will allow you to make the best guess (try as a layout table, try something else).

DA: Rabi's argument: if you can't do it for the most complex case - then don't do it. What's too difficult? The argument that "it's too difficult" doesn't wash.

JG: We've been down this road and the intermediate solutions did not work. We said that the DOM was the best solution. Perhaps the main issue against DOM has been timely access to the information. I think that concluded that the UA shouldn't try to make a graphical table rendering accessible to speech and braille as well.

/* 14:50 Break */

JG: I think it's a mistake to try to communicate structure through the graphical table presentation on the screen.

DA: Tables are logical structures. However you render the structure, the logic of the structure must be preserved. However you're rendering it.

Rabi: The only way to preserve the logical structure for navigation is to go back to the HTML.

WAC: There are well-marked up tables. For those, you should be able to get at information as the author intended.

JG: When we had 20 navigation checkpoints, we hit a deadend. There were always exceptions. So we decided that when you render speech, you address the needs for that audience.

RT: The problem you're dealing with is similar to the more generic problem of finding data on the Web (for which XML should be an improvement). If you're trying to search, how do you distinguish the semantics of what you've found. With XML, you can get out more information. There's an inherent limitation about HTML tables since they way they are used in practice doesn't give you direct view of the logic behind the table. It's an artifact of the graphical world that we use the TABLE element out of the inherent logical chaos.


IJ: Let's examine the checkpoint on table metadata. Is it a P1 requirement?

Rabi: The visual rendering of the table is a visual artifact (like lines in SVG).

DA: As to whether 7.3 and 8.1 are linked: yes; GR answered that this morning - you have to navigate to get to a place.

WAC: I have a few points:

KB: I want to say in different words what JG said: we're looking at graphical desktop browsers. If the browser is rendering visually, we need to address access to tables visually (e.g., using scrollbars, page down, etc.). Rather than serve as a bridge to ATs, provide that information to ATs through the DOM. So for 8.1, part of this checkpoint is met by checkpoint 6.1: implementing the access features of W3C specifications. I'm not sure we need 8.1 if covered elsewhere.

GR: I'm not opposed to using the DOM to walk the tree. The bottom line is authoring practices: misuse of markup. Also, lack of implementation of axis/scope/caption/summary. If we push everything off to the DOM, it's meaningless unless all the pieces are clearly marked up and defined. I'm not asking for repairs of poorly marked up tables; however, for proper tables, the information needs to be made available. If we say "Get everything in the DOM" we need to ensure that what is needed is in the DOM in the first place.

DP: I like the idea of leaving checkpoing 7.3 as is. We have a good foundation for the guidelines in two areas: interoperability; accessible rendering no matter how you render them.

IJ Proposed:

WAC: To click on something means to give it focus. You need to focus on the table (identify it).

DA: There are two types of contextual information in a table about a table cell (content + context).

GR: I don't know what it means that graphical is graphical and speech is speech. With the contextual point of regard, the only way to get the simulated right click is when there's no focus on the page.

DB: You don't need the focus on tables: you could bring up a list of tables and then query them. In 8.1, we chose language that was vague enough to allow communication of information to ATs.

WAC: We seem to be arguing about techniques. The checkpoint needs to be general enough to allow for future solutions (RDF).

IJ Proposed (again):

WAC: 7.7 could be a technique for 2.1 if 2.1 were not just access to content. You also need efficient access to content. It may be so inefficient to access content serially that it becomes an accessibility issue.

DA: So what does a desktop graphical browser have to do for 8.1? We need to make it clearer so that ATs can get the information.

JG: The DOM.


Action Ian: Propose new checkpoints to the list.

Guideline 8

Issue 163

Proposed new checkpoint on "Favorites" functionality

Resolved: This is not an accessibility issues.

Guideline 9

Issue 148

GR: You may submit a form inadvertently by using "return" with an AT that handles that key specially. (Checkpoint 9.3).

WAC: We shouldn't be specific about what key to use since it varies according to browser. There are serious authoring issues here.

Action Wendy: Take back form submission to GL to discuss issues related to inadvertent submission.

Resolved: "Return" may mean explicit submission according to content. There are authoring issues. No change in UAGL.

Guideline 10

Issue 112

Split checkpoint 10.1 into two separate checkpoints for author and user agent input functionalities and mark as an issue during last call.

RS: What API?

JT: Leave 10.1 and 10.2 as is (split, P1 and P2).

DA: I need to know what the "current" config is since the static documentation doesn't suffice.

MQ: Leave as is.

RS: If we make this a P1, there should be a way to support this. Does MSAA do this?

JT: Put up the information in a dialog and then it will be available through MSAA.

DA: Falls under 5.3 (programmatic access to UI).


RS: If we make this a single P1 checkpoint, we need a technique.

MQ: Our technique is to update the help files dynamically. But this doesn't satisfy the communication through an API.

Action JG: Add Issue:

Issue 129

Need to clarify 10.3 ("Allow the user to change and control the inputconfiguration. Users should be able to activate a functionality with a single-stroke (e.g., single-key, single voicecommand, etc.).)

IJ: The clarification is: the user doesn't have to be able to have single-key access for every functionality. But does need single-key for some functions.

DP: You could configure different modes so that given enough modes, you could get single-key access per functionality.

Clarification: we're not talkingabout macro capabilities.

Rabi: With my palm pilot (text only). the keyboard has


Issue 130

Proposed rewording of 10.5: Avoid default input configurations that conflict with operating system navigation, control, and access conventions.

Rabi: What about cross-platform consistency?

DA: I think this is a priority issue. I think it's good to have cross-platform consistency, but consistency on the same computer is even more important.

Rabi: By doing this, you can never have a product that works across all systems.

JA: Another priority issue 10.3 would allow configuration.

WAC: Even when developing cross platform, you should be aware of the conventions of the OS.

IJ: I don't like the change since it excludes some UI cases.

Resolved: No change.

Issue 131

Proposed change in wording of 10.8. Does this mean reconfigure where components in the content display and feature control parts of the UA are?

Resolved: Add clarification to the document (e.g., to the glossary) that "user interface" means (for the purposes of this document) the UA's interface, not the additional components provided through content. Ensure that references to "user interface" therefore appropriately distinguish the two cases.

Issue 134

Resolved: This is addressed by resolution of 129.

Issue 149

10.6: Wording (delete "and software") and confirm Priorit

Current: "Allow the user to configure the user agent in named profiles that may be shared (by other users or software)."

Resolved: "Allow the user to configure the user agent in named profiles that may be shared by users." Add a note that profiles should be importable by the same UA on other machines or across the network.

Other issues

Issue 120, Issue 121

Resolved: Addressed earlier by adding divisions to guidelines, categories to checklist, and introductory text. Also by definition of "user interface" in 131

Issue 136

DA: It makes sense for UAs to make available their claims on the Web.

Rabi: If you have a version of a browser that's not changing on your hard drive, it makes sense to have the details on your disk.

DA: Note that for different versions, the URI would change...

Rabi: I think that this is just a technique. The UA developer could make available in documentation.

DA: I want access to the claim before I purchase the software.

Action Ian: Repropose the delivery mechanism to allow documentation as an option. However, the claim must be accessible.

Issue 153

"We need a well-defined interface in the middle to best combine the expertise of screen reader developers with the expertise of application developers. Until this definition has been worked out, it would seem best to drop (postpone) the conformance rating altogether?"


Issue 170

How can UAs "stay" accessible when there is a mass of inaccessible content?

Resolved: No - not limited to accessible content only.

Discussion of proposed teleconference time

JG: Since the bridge is not available on Thursday at desired time. Proposed 2-3:30 pm ET

Action JG: request that time and send to list.

Adjourned 17:30