Minutes from 16-17 November UAWG face-to-face at AOL

Nearby: Agenda Meeting page Group photo (description)

Below: 17 November minutes

16 November


At AOL: Bijal Shah (Netscape), Debbie Fletter (Accessibility point person at AOL), Jon Gunderson (Chair), Denis Anson, Eric Hansen, Rich Schwerdtfeger, Al Gilman, Ian Jacobs (Scribe), Harvey Bingham, Scott Totman (AOL)

Phone: David Poehlman, Mickey Quenzer, Jim Allan, Gregory Rosmaita (after lunch)

Description of participants in photo: Back row from left: Ian Jacobs, Denis Anson, Eric Hansen, Jon Gunderson. Front row from left: David Poehlman, Al Gilman, Debbie Fletter, Harvey Bingham.


JG: Please note that if we don't have implementation experience, we will have to spend time at Candidate Recommendation status

EH: I would not want the document to get stale in CR for 6 months.

RS: This is a complex document. Few UAs will conform when the document becomes a Recommendation. If there are really sticky issues, we should push them off to the next version

AG: A guidelines document is somewhat different from a lower-level technical specification. It's not clear that W3C understands how to handle guidelines entirely. I think it's ok to have some checkpoints be future-looking.

DA: We need to remember that this document is to promote accessibility, and we shouldn't sacrifice accessibility in order to get the document out faster.

JG: If we know about a problem but don't have solutions, we may want (in another document) to spend time in CR to get developer input.

MQ: It is possible to note in the document which issues are important but not entirely implemented yet.

Issue 321 Equivalency relationships and the wording of checkpoint 2.3

Refer to email from Al on bindings.

JG: I think there are two things going on in parallel

  1. WCAG says to create, ATAG says help people create them, UAAG says make them available
  2. Hierarchical definition track and use of precise language.

DP: Ascii art as braille is not very helpful

EH: WCAG requires text equivalents for non-text content. But generally speaking, an equivalency target doesn't have to be accessible.


  1. It is critical that user agents implement the format. Talking about author's intent is problematic (and how to capture it in the format). We want the user agent to inspect the markup and to offer substitutes. But the user agent needs to give the user the ultimate choice.
  2. I think we are in agreement on requirements, but not language. There are some cases where polarity is clear (e.g., IMG/alt). But in the discussion of equivalence, we are also addressing the case (e.g., SMIL), where the "ruling" case is not clear.

JG: I think in PF they are moving away from specific markup to more general solutions that also benefit accessibility.

EH: I think that some requirements such as making all alternatives available (including those that don't have clear accessibility imlications such as alternative languages) fall under checkpoint 2.1. I think that the definition of equivalency is an assertion about accessibility of pairs of content.

RS: I think the bottom line is text equvalents.

AG: Because of cases like smil, where the accessibility impact may not be in the markup, if you don't capture the general case in the UAAG, you miss the special case of accessibility. I think that alternative languages is an accessibility requirement.

EH: Refer to my comments to the SYMM WG (Member-only?) about needing additional markup to identify accessibility content explicitly. If the markup is insufficient, you can't have rationale support for accessibility.

AG: I think that you should make the link to accessibility not in the definitions but in the checkpoints or at the guideline level.

EH: If you unbind the terms from the accessibility implication, the WCAG definition of non-text element falls apart. It doesn't handle, e.g., ascii art and scripts. These consist of text characters but are "non-text elements". So if you define text element as only being composed of text characters, you break the WCAG definition. If you are willing to tinker with WCAG language, you can shift the accessibility criterion to other definitions or spell it out in the checkpoint.

AG: Fuzzy definition not a big problem for WCAG because they are speaking to the human author. If there were something that the UA had to do automatically in software, we would have a problem since the definition is not good enough. But we don't have that problem for alternatives.

IJ: But we do for 1.5, for example.

AG: But then you can talk to authors again (the UA doesn't have to do anything).

RS: We need to be able to have access to the equivalent so that we can render it in other modes. In the UAAG, we have no control over what the author did. I think we should refer to WCAG and address the problems there.

DA: I think our problem here is that we are talking about things with linguistic content.

EH: Another way of talking about text elements is that it has a quality of "rendering independence". The trimodal approach is not totally open, not total independence.

AG: I think the improvements that we're talking about are good and should be in WCAG 2.0. But for UAAG 1.0, you need to move forward.

EH: I wouldn't use the word "equivalent" however - I would use another term.

IJ: We already proposed "alternative"

AG: Check out how ATAG uses "alternative". That should work.

/* AG notes that people are reading glossary entries as definitions */

IJ: So rationale for broader 2.3:


Action IJ, EH, AG: Propose new definitions for terms in question (equivalence, text element, etc.)

Issue 322

Refer to issue 321.

Issue 323 Using accessibility APIs rather than standard APIs to make non-W3C based content accessible

RS: I think you can differentiate standard APIs used for keyboard and mouse access to support physical disabilities from the actual rendering to the screen (e.g., in the case of Java or vector graphics). The accessibility API provides the same information in a better format than the output API.

IJ: Note that 1.2 still helps ATs that use an offscreen model. Be careful about removing the requirement to use the standard output APIs.

RS: MSAA and Java are about device-independent access (at the component level), access to pre-rendered content. They do not support the standard OS features for mobility access - that's the role of the application.

JG: We can split 1.2 into input APIs and output APIs (support for higher-level first, otherwise standard output APIs).

AG: So ATs that don't implement MSAA lose.

RS: There are cases where MSAA doesn't support all text. They're fixing this.

IJ: Note that in Princeton we explicitly decided to require all standard APIs, and suggesting higher-level APIs (not requiring them).

RS: Only recently did MSAA add access to element content. The Java approach: we knew we had to run across several operating systems, so we created an API to access text independent of platform. In that particular case, you have a solution that is the "only solution" for that platform.

Proposal: Change 1.2 to be "Use accessibility APIs, or if you don't, use standard device APIs".


AG: There's an issue about the integration of input functionalities with output functionalities.

RS draws a diagram showing input that goes through device-independent layer, then system access feature layer. Output goes through system access features layer first, then device independent layer.

RS: UAs must:

JG: So we are saying:

RS: Support accessibility APIs plus the DOM. Where they don't support text, use system APIs. Note that lots of people implement the accessibility APIs.

AG: If the UA supports two ways to get at the information, that's enough.

RS: Support system access features (e.g., sticky keys, etc.) [Covered by 5.9].

RS: JDK 1.4, when it comes out, will support all of DOM Level 2.

AG: Distinguish three classes of API: MSAA/Java (access), DOM, device APIs.


AG: Make clear that information available as text must be available as text to the ATs (bits written to the screen don't count). Make the text case a clear example.

IJ: Note that the Note needs to be edited in light of this. And the part about not bypassing the standard output API is deleted.

AG: I think that the fact that the spec supports access to information through both the access level and at the DOM level is part of the reasoning why all of the info needn't be available at the device level.

RS: Need to ensure that there's documentation about how to have access to these APIs.

Issue 324 How do developers interpret the phrase "appropriate for a task" in checkpoint 6.2

/* Scott Totman arrives */

IJ: Are we, in effect, requiring all conforming user agents to implement one or more W3C specs?

JG: People can create xml interfaces to documents in formats that are not in a w3c format.

IJ: How do you reduce the instances where UAAG requirements need interpretation?

DP: WCAG requires use of accessible formats. Adobe is trying hard to make a user agent that is responsible for rendering their content. I think they fall within our purview, but their format may not fall in the scope of WCAG.

RS: Note that the latest release of MSAA doesn't support access to tables.

JG: Recently I was playing with SPSS (a statistics package) and you could output the results as HTML. One idea is to require output in at least one W3C format.

IJ: That makes it an authoring tool.

AG: Is a piece of software that doesn't implement at least one W3C spec really a Web app?

AG: One approach is to say that we don't have enough experience with the accessibility process for PDF (e.g., WCAG 1.0 doesn't cover) and therefore that shouldn't be our focus today.

HB: XSLT could be a valid way to get around this, but even after the transformation you might have an inaccessible result due to lack of information in PDF to begin with.

RS: We are starting to see formatting objects on the Web...

AG: I agree with Ian - to what extent can we write this document to be format-independent, and to what extent should it push people to use W3C formats. This is a balancing act we are stuck with. I think it's a practical problem that for W3C formats, we have access to the specs and it's easier to be clear about general principles. Yes, we'd like to write functional requirements to help Adobe promote accessible practices, but it's not so clear that we are in a position to write general, clear requirements.

AG: The realities that we're looking at are like APIs: W3C formats are like APIs - they deliver the best engineered solution today for accessibility. We should have something in here to promote those formats.

HB: We have problems of W3C Recommendations are in conflict.

IJ: Note that "available" has some wording around it in techniques about implementation schedules.

AG: You shouldn't have to go to the Techniques document to get this information.


EH: We could say that we don't have specific criteria for identifying what is "appropriate for a task" and leaving as it.

HB: These specs need to be open.

IJ: I have a problem saying "accessible spec" since we don't have a spec that explains what that means.

AG: You need the format plus the software. You can say in a Note that the developer needs to implement functionalities in the manner of W3C specs.

EH: This reminds me of our discussion about the scope of our repair requirements. When you talk about outputting PDF as HTML, that's a repair functionality.

AG: Support format that can conform to WCAG.

IJ: Issues at stake:

  1. P2: Implement W3C specs; if you don't, implement formats that allow WCAG-conformant authoring (at any level of conformance).
  2. P2: Conform to implemented W3C Recommendations
  3. Note: Support deprecated features (legacy requirements)

    AG: Developers will do this anyway because of user base.

  4. Note: Implement the latest version (improved accessibility, we hope) that includes accessibility features.

    RS: Support the version that has the latest accessibility features (which may not be the very latest version of the spec).

  5. Note: Define "available" a little better

    IJ: This seems to come down to time schedules.


Action IJ: Draft new language for 6.2

/* 12:30 Lunch */

Issue 325 Checkpoint 5.5: API notification of content change in one viewport that causes change in another

Resolved: This is covered as part of 5.5. Include as a Note or technique.

AG: The example is in the DOM Level 2 Mutation events module.

JG: MSAA is another example: it sends events to ATs when content changes.

RS: The association between viewports is not part of DOM Level 2.

Issue 326 What if the standard APIs do the wrong thing?

Resolved per 323.

Issue 327 Add requirement for support of charset expected of each API?

AG: Proper character encoding is required for proper text handling.

AG: This could be a requirement that is included in a general "conform to specs" requirement. Otherwise, I think this needs to be a separate requirement for handling text properly, and that is very important for accessibility.

Resolved: Include a P1 requirement for proper support of character encodings for each supported API. You can't break text.

Action IJ: Get wording from Martin for this requirement (e.g., "conform", "implement", etc.)

Issue 328 Checkpoint 4.12: "Words" per minute bounds do not scale internationally.

IJ: One option is to make the bounds informative for English.

GR: If we do, we should get input from non-English speech engines to suggest other bounds.

GR: Some speech synthesizers allow rate control in terms other than "words per minute"

/* Question of 5% increments */

MQ: With JFW, you can use page down (granular navigation)

MQ: Some of this depends on hardware (e.g., incremental changes)

DP: I think it would be a clear requirement for software synthesizers to provide different granularities of rate control.

DP: Now that my technology allows me to change rates, I do this quite often.


Issue 329 Checkpoint 2.7: Clarification required about boundaries of "recognized but unsupported"

Refer also to issue 362

IJ: Top down:

IJ: There are different issues for graphical rendering and speech rendering. For graphical, encoding (should be) sufficient to tell UA which character (though UA may not have glyphs). For speech, need more than encoding information, need natural language information.

Apparent requirements:

IJ: (Phill Jenkins comment #3): Why is this an accessibility issue?

AG: This is an issue for speech users more than cognitive users (due to serial access).

IJ: (Phill Jenkins comment #4): What if UA/AT doesn't know what languages are supported?

AG: They can allow pass-through if they want. This is user control - the user needs to be able to say "don't pass this off".

Resolved: Delete "marked up in a recognized but".


Issue 330 Definition: Natural language / Writing system / Script


Issue 331 Add a requirement for configurability based on natural language preferences?

AG: This would be nice to have, but may be too big a new requirement. This is all available in CSS2, by the way.


GR: We should talk to the I18N WG at the plenary in 2001.

Issue 332

Proposed: A P1 requirement that the user must be able to choose from all available dictionaries and to override author-specified and user agent repair of unmarked up natural language.

JG: HPR 2.5 already does this. I suspect that JFW does this as well.

IJ: For graphical rendering, NN lets me choose encodings.

AG: Lynx allows you to force encodings as well.

EH: Is this a requirement just for users with disabilities? Or does it affect everyone equally? Not sure that this should be a P1 requirement.

EH: I don't think I support the P1 level because, in part, we should be expecting WCAG-conformant content.

MQ: I don't think this is a P1 requirement. It's not a disability issue.

RS: I don't think that this is a P1 requirement.

IJ: Who feels that this is an accessibility issue specifically: AG, DA, GR, DP.

Is not an accessibility issue: BS, ST, RS, MQ, HB

EH: I could support a P3 requirement, but not if several types of support are required (charsets, etc.)

GR: We do have a requirement for access to all content.

IJ: Strong support for speech P2 requirement for dictionary selection: DP, GR, DA, AL

Mild support: EH, IJ

No/Low support: Everyone else...

IJ: Note that 4.14 is about configuration, not control.

Resolved: P2 requirement for configuration of preferred dictionary.

JG: I think we should spend more time on this in the next version of the guidelines. Also, current technology is already doing this.

Issue 333 Checkpoint 4.2: Clarification required about what "all text" means

Resolved: This is a clarification and the WG supports the proposal:

Issue 334 Checkpoint 7.5: Input to search capability not always "plain text" (may be speech, braille)

IJ: I think that this is not a search functionality (string matching), but an input method issue (that will vary greatly).

JG: We require standard I/O, so I think this is covered.

AG: There are technologies like SoundEx that do phonetic matching, but we haven't include such a requirement in this document.

Resolved: This requires a clarification - matching within the character set of the document. For information about input, refer to the API checkpoints.

Issue 335 Checkpoint 9.5: Need to consider international input methods in single-key requirement

JG: We don't have a requirement for single-key character input.

Resolved: No change to requirement. Perhaps add clarification that 9.5 is not about character input.

Issue 336 Checkpoint 9.2: Delete "accessibility" from "OS accessibility conventions"?

EH: Change this to P2 and saying more strongly "Do not" instead of saying "Avoid".

JG: Note that 5.8 is a P2 to use OS conventions.

DA: You should be able to provide other input configs if they are better.

GR: There are two things going on:

  1. Avoid conflicts with system conventions
  2. Don't mess with bindings explicitly for the purpose of accessibility.

IJ: We might add at the end of the checkpoint "for input".

EH: You can better justify the P1 by narrowing the scope this way.

AG: My problem with saying "for input" is that you are creating a total input/output division and that's not how GUIs work. You shouldn't interfere with some output features either (that may work with input configs, e.g., sound sentry).

AG: It's important to support conventions of the OS even if they are not specifically for accessibility (e.g., F1 bound to help) - that standardization promotes accessibility.

RS: The default input config should respond to OS accessibility conventions.

JG: Might add a note to 5.8 that using the std keyboard config promotes accessibility.

EH: Is there a danger that access features might be so broad as to impose burdens on AT developers (who would have less space to work in).


Issue 337 Conformance: Implementing the standard API for the keyboard "after IME"

AG: I think that on some platforms, there may be several APIs for the keyboard.

IJ: Then use the plural in 1.3.


Issue 338 Editorial: Edits to Guideline 1 prose re: easy access

Resolved: Incorporate editorial change.

Issue 339 DOM Level 2 requirement for HTML since returned to Working Draft

RS: Proposed:

Action IJ: Talk to the Director about this proposal

Issue 340 Editorial: Use "refer to" for references, otherwise "see" for informative cross-refs.

Resolved: Adopt the proposal

Issue 341

Refer to issue 329

Issue 342 Editorial Checkpoint 3.7: Clarification to checkpoint wording

Action IJ: Deal with it.

Issue 343 Editorial: Checkpoint group header for multimedia checkpoints v. continuous-time

Action IJ: Deal with it.

Issue 344 Conformance: Delete reference to Internet Media Type

AG: I think that in the content type section, it's useful to talk about trimodal rendering

Resolved: Delete the reference to RFC2046. These are about data types, not the user experience.

Issue 345 Checkpoint 1.1: Is requirement concrete and observable?

JG: We've had three comments on this one:

JG: Some options:

DA: Consider voice input: Naturally Speaking is close to hands-free. ViaVoice requires some mouse/keyboard input.

JG: Full voice input may not be in scope for this document.

JG: We wanted keyboard access for all functionalities. If we reduce the requirements for other input devices (mouse, voice), we will address some requirements from users.

IJ: Is full functionality through the mouse an accessibility requirement?

DA: Yes. Some people only have access through head pointers (and cannot use voice input).

JG: You can exclude voice from your conformance claims.

IJ: It might be useful to have a "voice" content label (but that would the the first input in this section, so I'm not so sure...)

GR: I would prefer to see 1.1 stay as is. In the conformance claim, have the developer have to specify which input APIs are supported.

AG: It's P1 to have all functions available through an API. If you've got the keyboard API there, the fact that you add another interface that does some of the functions should not degrade you from having Single-A conformance.

RS: If the OS is controlled by voice, your application should also be controlled by voice, period. If it's controlled by keyboard and mouse, then those should be the input APIs.

IJ: That's covered by checkpoint 1.2.

Some ideas:

AG: A voice browser running at the end of a telephone is not really the focus of these guidelines.

DA: Keyboard APIs already let you do mouse things and vice versa. There are examples of full mouse accessibility through the keyboard API.

JG: Our goal with 1.1 is to access functionalities of the UA. The APIs used to do that are not as big a deal.

EH: What if we limit the scope of 1.1 to keyboard and pointer API.

EH: What about this: All functionality has to be available through the keyboard or mouse API.

GR: Proposed: Leave 1.1 as is, but add that to conform you may require emulation via a standard API.

RS: Not required, here's an example: you may do voice recognition, but be able to do some things in a device-independent manner. If you claim support for a specific input modality, then the user with a disability should expect that all functions are available through that modality.

JG: Introduce modality in the section on conformance. Talk about the checkpoints you must satisfy to make a claim for that modality.

EH: I hear:


Adjourned at 18:00

17 November

Start at 9:00


At AOL: David Poehlman, Jon Gunderson, Denis Anson, Jon Gunderson (Chair), Rich Schwerdtfeger, Al Gilman, Harvey Bingham, Ian Jacobs (Scribe), Debbie Fletter

By phone: Mickey Quenzer

Issue 346 Checkpoint 2.4: Proposed split: merge part with 2.3, leave 2.4 as synchronization requirement

AG: Note that, for example, for SMIL, you don't know whether something is captions or not. Therefore (as we discussed yesterday), you may have to cast a broader net for 2.4

IJ: There's an issue that 2.3 doesn't necessarily require synchronous rendering.


IJ: I still think that text up front emphasizing universal design is a good idea as well. Note that since 2.3 and 2.4 now will share a Note (potentially), this might be pulled out.

Issue 347 Checkpoint 3.2: Is silent/invisible rendering really desirable? What is definition?

IJ: Reminder - we said that invisible/silent was ok since the idea was that the content wasn't in the way.

RS: Technically possible.

EH: Rendering means rendering to the user. I don't like using the term "rendering" to mean that content is delivered but not to the user.

AG: One problem is that the rendered content may trigger some events.

RS: If you're playing and you want to maintain synchronization, you keep that in memory and watch events. You can write back to the screen if the user wants the content.

IJ notes that "rendered" is not defined in the spec.

DP: If you run video in a minimized window, that gets it out of the way. If you are using an assistive technology, you might rotate among windows and the AT would pop it up.


Issue 348 Editorial: Selection, focus, point of regard (state v. interaction)

AG: You need to be able to style the pseudo-properties focus/select. You don't need different rules for styling: what you style is the sum of content + the state of the user's interaction. Visited and non-visited links is also state information. You style all the properties of content: both static and dynamic.

IJ: Note that our requirements were developed in parallel (we have about the same for content and selection/focus).

JG: Is the cost of reorganization worth it?

RS: Note that CSS lets you style focus but not selection. I think we should push this reorg to another version.

Action IJ: Propose new checkpoints to see how it feels to harmonize the requirements. If the WG isn't thrilled, we will leave document as is.

Issue 349 New requirement for support for deprecated features (currently informative in 6.2)

Refer to resolution of issue 324.

Issue 350 Checkpoint 7.3: Is this really different from 7.4?

AG: I retract this issue.

AG: Note that pwWebSpeak, you can have content rendered and focus is moved automatically by the software - the user doesn't navigate the active elements. You need to get the focus to all elements so that you can interact with them. That may not require navigation on the part of the user. Navigation assumes a geometry of the content - it's a more structured process than the minimal requirement.

IJ: The user must be able to activate all active elements.

Action IJ: Add some more explanation about the difference between 7.3 and 7.4.


Issue 351 Conformance: Definition of priorities not consistent with WCAG definitions

JG: Note that for 10.1, if the UI is difficult to use and the documentation is difficult to use, the user may not be able to use the software. Therefore, not a symmetric usage.

IJ: We are "consumers" of WCAG in this case.

Resolved: We note AG's comment. We don't have new data that leads us to think that a change is necessary.

Issue 352 Checkpoint 8.4: Must outline view be navigable?

AG: I thought that the negative statement (doesn't have to be navigable), that that's misleading. If you implement 7.6 and 7.7, you will be creating a virtual outline view by what you can move to.

IJ: The difference with 8.4 is that it's a rendered view.

AG: The outline you present in 8.4 is what is navigable in 7.6.

RS: On the issue of navigable - if the outline is not navigable, some of the structure may be difficult to understand for someone who is blind.

JG: You can do navigation without collapsing to an outline view.

MQ: Why wouldn't you want the outline view to be navigable?

JG: You do want it, but it's not a requirement.

AG: If you are going to make the negative statement in 8.4, tie this in more closely to 7.7.


Issue 353 Checkpoint 8.2: Don't use color alone should be a requirement.

AG: I want the default presentation to be accessible. The default presentation of the selection/focus should not rely on color alone.

EH: Does the default requirement justify the P2 rating?

IJ Proposed: P3 requirement that default configuration not rely on color alone.

MQ: There's a problem if the styling for visited/unvisited conflicts with focus/selection.

IJ: But is it a problem if the user can configure the presentation of all of these things?

MQ: The user should be warned if there's a risk of one style obscuring another.

AG: I think that you ought to put the default config in the same requirement as the config requirement (since they will be implemented as a package).

DP: On warning the user when styles collide - Perhaps not for this document, but for the UA documentation.

MQ: Wherever we can, I think we should include rationale for the requirements (e.g., large-print users).


Action IJ: Propose new checkpoints/modified checkpoints.

JG: I would note that this is a new requirement.

Issue 354 Checkpoint 7.5 editorial: Clarify usage of point of regard / viewport

Resolved: Edtiorial.

Action IJ: Proposed fixed wording.

Issue 355 Conformance: OS features used must be accessible

AG: I retract this issue.

EH: Note that if the OS features are adopted, then they are in scope and it's natural that they must be accessible. OS features are just other components.

AG: I propose changing wording to "provide access to accessible adopted OS features".

Resolved: Editorial.

Action IJ: Point to composite discussion.

Issue 356 Editorial: "Scope" v. "Limitations"

Resolved: Editorial

IJ: I'm happy to make this change.

EH: I'm fine with that too

Issue 357 Conformance: Problematic applicability provision re: content properties

AG: The current language includes two parts:

IJ: We certainly didn't mean the second part.

There was discussion about PDF and our discussion of checkpoint 6.2 yesterday.

DA: There's potential abuse here that people will claim conformance for formats that "don't allow" control of any properties.

IJ: It is my interpretation that 6.1 doesn't always apply: if a spec doesn't include any accessibility features, but the spec is accessible.

AG: For PDF, background images, Adobe can recognize a supertype (all images). Therefore they can implement a policy that addresses this issue.

IJ: I want to say:

IJ: Note that plain text doesn't meet the needs of all users with disabilities. Would we want to say that a viewer of plain text could not conform to the UAAG 1.0 because the format it renders doesn't (potentially) meet the needs of all users with a disability?

Action IJ: Add to techniques a link to Adobe's accessible PDF information.

Action IJ and AG: Revise the applicability provision and send to WG.

Issue 358

Refer to issue 321

Issue 359

Refer to issue 322

Issue 360 Checkpoint 2.2: What if time interval controlled by server?

AG: An example of time-limit on the server-side: W3C meeting registration - the cookie expires after a certain period.

JG: I think we agree that this is not within the UA's purview if the server controls the time interval. This is an authoring issue.

AG: WCAG doesn't address "the whole process" today.

DP: I've had problems while shopping online where my shopping session times out and my shopping cart is emptied automatically.

RS: This checkpoint should say "where the UA has control over the time parameter"

AG: I'd like a note that the actual problem is a service.


Action JG: Take the issue of server-side control of timing to WAI CG.

RS: Security issues, if done properly, should be controlled by the server, not left to the user agent. My response to Phill Jenkins, is that this is an authoring issue.

AG: I object to this - I want to say that security + accessibility should be addressed by the PF Working Group. This can be done in a format.

DF: This is a capacity issue - there are users who complain about the timeout and about being interrupted. We don't have a solution today.

AG: There are solutions (e.g., upgrades to increased capacity, and they have priority to these upgrades since it's a bona fide need).

To address Phill's comments:

IJ: What about the question about what the UA is expected to recognize in a script?


Action JG: Propose a list of things we are expecting UAs to recognize in scripts.

RS: There's an additional problem - plug-ins could have control and the UA won't be able to recognize the delay.

RS: There must be a mechanism in the UA that can be accessed by scripts and plug-ins to tell them that the user needs X amount of time minimum to respond to a timing action.

JG: I think that WAI needs to be doing a lot more work on scripting/plug-ins.


Issue 361 Checkpoint 4.14: List of options is too long / consider ease-of-use

AG: The list of speech characteristics will grow. You don't want to be locked in to a list.

IJ: History - we used to have a broader requirement for control of speech characteristics (in general). The WG explicitly chose this list (and confirmed it at the 24 August teleconference).

MQ: Cheaper synthesizers will not support the full list we ask for.

RS: I think that the UA should support configuration of all characteristics supported by the speech synthesizer.

JG: SAPI lets you pick persona, pitch, speed, volume. If picked this synth and provided access to the full range of values offered by this synthesizer, would I conform?

DP: Depending on the synth, some of these properties may not be supersets of others (which is Phill's suggestion).

EH: Should we say something like "support at least one synthesizer that provides such capabilities"?

DA: You have the capability if the synth offers it.

MQ: We can't require people to have a particular synthesizer.

JG: We are not - we are requiring a synth with particular functionalities.

DP: This is not intended for users who are blind. We are talking about content delivered as speech.

AG: I don't agree with making hardware synths out-of-scope. But I think that there should be an escape clause that for what the synth doesn't support, the UA doesn't have to allow configuration. The requirement is punctuation plus three degrees of freedom (like colors, fonts, plus one...). You need to have control over reading punctuation (period). I think that differentiation is important. Then list the 6 characteristics and say that if these are available, then must allow user to choose from among them.

IJ: Reminder - this checkpoint was written to say "These are the required characteristics". Thus, the exception clause goes against this design.

MQ: Every synth has a different definition for the terms we have in our min reqs list. Note that some speech plug-ins don't offer keyboard access...

JG: Voice processing software can generate punctuation and handling numbering even if synths don't have this capability natively.

AG: I agree with Phill that the current list of min reqs is too long. If we pull back, we could have a requirement the default style sheet has a mapping from supported characteristics to CSS-like properties. It's a requirement that the UA not ignore stress because they say I don't recognize the property.

IJ: Note - we don't have in our conformance provisions a requirement to identify the speech engine that is used to meet the requirements.

DA: Content is important - puncutation. UA can control that. Speech engine has control of dynamics.

AG: Some of these requirements came from people having hearing disabilities, and you need the "rendering space" to accommodate these needs. People with lower bandwidth hearing need to move the center.

MQ: I think we need to keep pitch in the list (for hearing impairments).

DP: Remember I18N requirements - you need to look at speech from the perspective of natural language (e.g., accents, etc.). Do we have information from playback organizations (e.g., Daisy) that we can use to help us?

HB: Daisy has addressed this. I don't know the details.

Action HB: Find out how Daisy addressed this



IJ: This implies that you have to conform to ACSS, doesn't it?

EH: Since this minimal list is "in scope" for conformance, I think that the idea of the full range of values is out of place.

IJ: Note that we have validated that the longer list of min reqs has been implemented in at least one speech synthesizer.

AG: I'm not sure I want to take pitch range off the list. But I don't want to talk further about it today - let's take it to the list.

EH: I think that anything that is scope implies that they have to be recognized.

Unresolved. Take this to the list.

Issue 362 Checkpoint 2.7: Clarifications required (e.g., is this an accessibility issue?)

Refer also to issue 329.

Action AG: Send a reply to Phill.

Issue 363 Checkpoint 3.3: What if scripts used for blinking? (also, other issues)


Issue 364 Checkpoint 3.5: Add plug-ins, clarify that on a resource-level (not element-level)

IJ: What's the diff between a plug-in and applet?


Issue 365 Checkpoint 4.12: Re-evaluate priority of increase/decrease and allow other techniques (also, other issues)

Resolved per issue 328.

Issue 366 Editorial: Please put direct links to WAI resources.

Action IJ: Do this.

Issue 367 Checkpoint 1.2: Clarification required for cross-platform implementations, published APIs, more


Refer to action item of issue 323 about checkpoint 1.2

Issue 368 Checkpoint 10.1: Use relative priority

Resolved: We disagree with the reviewer. One example is that WCAG requirements for tables only level single-A. That's just one reason why, as a consumer of WCAG, we require Double-A.

Issue 369 Checkpoint 7.4: Conformance possible if you can't get to elements with event handlers?

JG: Recall that CMN was a big proponent of device-independent access is important. One possible technique is to query the document for event handlers and activate them.

IJ: Note that access to event handlers possible through DOM Level 2 Core, but higher level API preferred. We don't require conformance ot the Events module.

JG: Recall big problem of event bubbling. It's thus problematic to include a requirement to navigate to event handlers since it's possible to make the whole document an active element.

DA: "Dragger" from origin instruments lets you move the mouse to a location and generate a double-click at a location. This one works with the Microsoft mouse driver.

JG: I think our change in 1.1 yesterday affects this. We went from an API requirement to a functional requirement. If you support the mouse, you must provide pointer-based event handling. If you're compatible with mouse keys, you can do the mouse movements with the keyboard.

RS: One problem with that: you don't know that something is active by visual inspection. You could use style sheets to indicate which elements are active.

JG: Recall that we said "explicit event handlers" in the definition of active elements.

IJ: We don't have implementation experience for navigation to elements with event handlers attached.

RS: Flash content may be attached to elements and may have event handling.

AG: You could have handlers that are specified outside the document.

RS: Need to clarify that what is active must be identified in markup (not through scripts).

RS: What about CSS ":hover"?

JG: That doesn't trigger a script, only style.

IJ: Another answer: style is disposable. If not, this is an authoring bug. Suppose you are using style sheets to expand the table of contents. It's an authoring bug to rely on style sheets alone (in my opinion).


Issue 370 Checkpoint 7.6: Clarification required on how important elements identified

EH: We aren't asking authors to mark up elements specially.

Resolved: Editorial

Action AG and IJ: Work on new wording.

Issue 371 Checkpoint 3.8: Priority should be raised from P2 to P1

Resolved: We do not consider that rendering speed is not sufficient to make a requirement a P1 requirement.

Issue 372 Limitations of standard APIs in conveying author's intent of functionality?

Issue 373 Checkpoint 10.5: Propose raising to Priority 1

Issue 374 Definition: Selection, current selection and use of inflected speech.

Resolved: Editorial

Action AG and IJ: Work on this offline.

Issue 375

Bug in the issues list. There is no issue 375.

Issue 376 Requirement that plug-ins be given focus

RS: I think that we already have this by virtue of our requirement of access to viewports.

IJ: For viewports that are included in a conformance claim, 7.1 covers this. But we lack a requirement that the UI focus be available to other software. I think that the issue is that the other application requires the right to process events in the user interface (mouse input, keyboard input, etc.). It's uncool to steal focus from other applications and not give it back. But is this an accessibility issue?


Action JG: Ask Microsoft if they think that this is a bug in IE.

Issue 377 Security issues and communication with other software

Action JG: As part of taking security issues to WAI CG (per issue 360), talk to WAI CG about security and accessibility issues related to access to content.

IJ: Note that this issue suggests that a UA may conform for some documents (those without security requirements) and not conform for others (with security requirements).

EH: Security is a very valid issue (we have to deal with this at the Educational Testing Service all the time for test scores). I think a Note that says that this is out of scope for this document.

HB: Digital rights management in general (copyright, etc.)

AG: It's not acceptable to lock out ATs. They must implement a security architecture that allows access. We can't just give Adobe blanket conformance. They need to adopt a suitable security system.


Action IJ: Draft a response to Adobe.

Action AG: Send info about portable point of sale to Ian for his reply.

Issue 378 Simplify language of document for non-technical audience.


Issue 379 Checkpoint 1.2: Exception when primary output (e.g., graphics) cannot be handled by the OS?

We think we resolved this per resolution for issue 323.

Issue 380 Checkpoint 2.3: What if equivalency relationship unknowable by format?

AG: If Adobe can provide an equivalent from a logical equivalent from the data structure, but they are unable to track where this goes on the screen, what do they do? Our 2.3 sounds very visually-oriented.


Issue 381 Checkpoint 2.5: Checkpoint text needs clarification

JG: If you read 2.5 in a PDF context, it makes sense that you would have trouble understanding this checkpoint: each glyph or line or curve is a non-text element.

AG: Yes, anything that's an "svg:g" can be considered a non-text element.

AG: I think that 2.5 was originally targeted at missing alt in HTML. That's a case where there's a recognized structure for alternatives and the alternative is missing.

JG: You could say that if the UA recognizes in content that an equivalent is missing, then it must be configurable to generate repair, etc.

EH: Add the same implementation Note if alternatives are to be searched.

Resolved: Three parts of requirement -

  1. Configuration part (same)
  2. Generation part (same)
  3. When to do this part: Whenever a (recognized) required equivalent is missing.

>Try to clarify language as well...

Issue 382 Checkpoint 3.2: Hard to do in many cases (e.g., when scripts used).

Action IJ: Ask Adobe why this is hard. We need implementation details.

Issue 383 Checkpoint 3.2: Add definition of "placeholder"

JG: Our model is the broken image icon that has to have a text equivalent. This should be covered by 1.5

EH: Placeholder could be text or non-text.

Resolved: Editorial

Action IJ:

/* Aaron Leventhal joins */

Issue 384 Editorial Checkpoint 3.3: Add an example of stock quote ticker

Resolved per issue 363 : 3.3 does not cover the case of scripting that causes animations that cannot be recognized by the UA.

Issue 385 Add requirement that component size increases when objects contained increase size?

AG: I think that the answer to this is recognized limitation: we didn't have consensus on the technical specification of how this should work.

JG: We expect to address general scaling issues in later version of the specification.

IJ: As a consolation, some formats define how scaling should occur, so by requiring conformance to SVG, scaling is covered for that case.

Resolved: UAAG 1.0 does not include such a requirement, unless general scaling part of conformance to specification (e.g., SVG).

Adjourned 3:30