Nearby: Agenda · Meeting page · Group photo (description)
Below: 17 November minutes
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.
Refer to email from Al on bindings.
JG: I think there are two things going on in parallel
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.
AG:
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:
Resolved:
Action IJ, EH, AG: Propose new definitions for terms in question (equivalence, text element, etc.)
Refer to issue 321.
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".
RS:
DA: MSAA doesn't handle mobility access features: sticky keys
RS: For input: MouseKeys, SerialKeys, StickyKeys, RepeatKeys, BounceKeys, ... For output: high-contrast and font size, font family.
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.
Resolved:
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.
/* 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.
JG:
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:
AG: Developers will do this anyway because of user base.
RS: Support the version that has the latest accessibility features (which may not be the very latest version of the spec).
IJ: This seems to come down to time schedules.
AG:
Action IJ: Draft new language for 6.2
/* 12:30 Lunch */
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.
Resolved per 323.
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.)
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.
Resolved:
Refer also to issue 362
IJ: Top down:
DA: This could be a problem for users with cognitive disabilities. One idea is to allow the user to say "don't give me content in these languages".
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".
Notes:
Resolved:
AG: This would be nice to have, but may be too big a new requirement. This is all available in CSS2, by the way.
Resolved:
GR: We should talk to the I18N WG at the plenary in 2001.
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.
Resolved: This is a clarification and the WG supports the proposal:
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.
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.
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:
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).
Resolved:
AG: I think that on some platforms, there may be several APIs for the keyboard.
IJ: Then use the plural in 1.3.
Resolved:
Resolved: Incorporate editorial change.
RS: Proposed:
publish a new UAAG that includes an HTML module requirement. This avoids forcing user agents to implement a DOM Level 1 HTML spec with known bugs.
Action IJ: Talk to the Director about this proposal
Resolved: Adopt the proposal
Refer to issue 329
Action IJ: Deal with it.
Action IJ: Deal with it.
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.
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:
JG: HotMetal provide integrates an onscreen keyboard.
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:
AG: This is about the user, not the API.
AG: You could satisfy 1.1 for three modalities by implementing just one standard API (for the keyboard).
IJ: It sounds like 1.1 is about native user interface and 1.2 is about APIs.
DA: You should not be able to conform for voice modality if you don't allow access to all functionalities through voice.
Resolved:
Adjourned at 18:00
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
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.
Resolved:
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.
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.
Resolved:
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.
Refer to resolution of issue 324.
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.
Resolved:
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.
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.
Resolved:
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).
Resolved:
Action IJ: Propose new checkpoints/modified checkpoints.
JG: I would note that this is a new requirement.
Resolved: Edtiorial.
Action IJ: Proposed fixed wording.
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.
Resolved: Editorial
IJ: I'm happy to make this change.
EH: I'm fine with that too
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.
Refer to issue 321
Refer to issue 322
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.
Resolved:
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:
AG: Any https URL implies a secure connection.
IJ: What about the question about what the UA is expected to recognize in a script?
JG:
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.
Resolved
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
Proposed:
Proposed:
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.
Refer also to issue 329.
Action AG: Send a reply to Phill.
Resolved:
IJ: What's the diff between a plug-in and applet?
Resolved:
Resolved per issue 328.
Action IJ: Do this.
Resolved:
Refer to action item of issue 323 about checkpoint 1.2
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.
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).
Resolved:
EH: We aren't asking authors to mark up elements specially.
Resolved: Editorial
Action AG and IJ: Work on new wording.
Resolved: We do not consider that rendering speed is not sufficient to make a requirement a P1 requirement.
Resolved: Editorial
Action AG and IJ: Work on this offline.
Bug in the issues list. There is no issue 375.
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?
Resolved:
Action JG: Ask Microsoft if they think that this is a bug in IE.
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.
Resolved:
Action IJ: Draft a response to Adobe.
Action AG: Send info about portable point of sale to Ian for his reply.
Resolved:
We think we resolved this per resolution for issue 323.
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.
Resolved:
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 -
>Try to clarify language as well...
Action IJ: Ask Adobe why this is hard. We need implementation details.
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 */
Resolved per issue 363 : 3.3 does not cover the case of scripting that causes animations that cannot be recognized by the UA.
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