By phone:
Agenda
Proposed: s/functionality/information and s/button/graphical icon.
Resolved: The checkpoint is only about messages, not all UI components.
Action IJ: Propose a new note to the WG (with graphics and sounds).
(Refer also to Issue 271).
CMN: CSS2 positioning. Problem with zooming languages that have no text flow (e.g., SVG).
IJ: I've also heard that arbitrary positioning isn't required.
MR: An issue about content being obscured. And if the user magnifies the screen, they need to be able to move captions.
IJ: I don't think you can make an absolute statement that one piece of content must not obscure another piece of content.
CMN: I think that Sausage SMIL Composer lets you more captions.
Resolved: No change.
CMN: The question is what's the minimal requirement? I think that:
IJ Proposed:
IJ: Does the player need to allow repositioning when it knows (e.g., geometries) that the content does not overlap?
CMN: Yes, when zoomed.
MR: One scenario when it's useful to overlap: when you're viewing on a small screen - or when your screen geometry is different from what the author intended.
MQ: The AT might be able to find the information when it's in a particular position.
CMN: I think that arbitrary positioning is what you need to be able to do.
IJ: Why in this case and not others (e.g., colors, fonts, etc.)
MQ: Putting alt content in another window may make it more available to other technologies.
CMN: I think that the checkpoint should require the user agent to allow arbitrary repositioning. For example, if captions overlap subtitles, need to move them out of the way.
IJ: I don't think the text says that today. Given the definition of "configure".
IJ: I hear two cases for minimal requirement:
GR: You need both at the same time in both cases (you need the synchronization)
KB: If I have narrow vision, need to move things into my range of vision.
Resolved:
Action IJ: Propose a Note stating the minimal requirement and emphasizing the goal. Add examples to techniques document.
Resolved: Editorial - make suggested change in light of other discussions on "author-specified" and the results of checkpoint 2.1
Resolved:
GR: There are fonts that people cannot use for a variety of reasons. At any size.
Resolved: No change.
Action:
Action CMN: Find out from I18N how to generalize the accessibility provided by sans-serif fonts.
IJ: Any minimal font size?
GR: I would make my font as small as possible to get more content on the page.
CMN: The use of micropayments is a technique in this case. The requirement is about spending money, but micropayments are just an example.
HR: Is paying the only bad thing that can happen when you can follow a link?
JG: The WG felt that this was important enough.
GR: I would have pulled out other ones (and not this one) but we were able to separate this one because of the micropayments draft.
CMN: Al Gilman said that this is a CD issue. You have to make it clear to people that their money is disappearing.
HR: I have problems with the current wording. I think the general requirement is to avoid that bad things happen when you follow a link.
CMN: I spoke to developers about a checkpoint for making available useful information (this was the original checkpoint). It was too ambiguous. Checkpoint 8.4 says "make available everything you know." But since paying money was more serious, it was special cased at a higher priority level.
IJ: Just because we identified one important requirement and not others, doesn't mean we should delete the first one. Also, the fact that we require making available all information (8.4) means you can avoid bad situations as well as pursue good ones.
Resolved: No change.
/* Break */
CMN: How does the author know what affects accessibility?
IJ: Read this document!
IJ: Does new support for the Thai language affect accessibility?
GR: Yes, if you're a Thai user with a disability.
RS: But that affects all users who speak Thai.
CMN: The things that affect accessibility are those things mentioned in this document. There are specific checkpoints about language support in the guidelines.
Resolved:
Resolved:
Action JG: Take this to the WAI CG.
Issues 253 to 276 were not part of the formal review but should be considered by the WG.
RS: MSAA does not solve all problems. It doesn't provide access to text in all applications. You need to do both. There are some ATs that don't support all of MSAA (for example).
HR: On the Mac, there isn't an accessibility API. Even for our PC, we rely on the offscreen model, in part because we cannot use MSAA on Win 95 because it's not internationalized.
RS: You are a UA with a custom control that MSAA doesn't provide access to. The AT (like a screen reader) would need to read the text that you drew to the screen.
IJ: Are you always required to use the devices?
RS: MSAA is limited today to standard controls. It doesn't handle well custom controls.
MN: MSAA is for getting input, not writing to the screen.
JG: There are two parts - the part where the developer creates objections compatible with MSAA, and the other where the UA gets events from it.
RS: For input, for custom controls, you want to be able to respond to serial keys.
MN: I don't think it's important. MSAA is just one of several technologies.
RS: You need to always support standard input since MSAA or others have nothing to do with standard input. For standard output ("Can I write to the screen or use MSAA?"), if you use standard controls you don't have to do anything anyway. If you are going to write a custom control, MSAA is not always reliable and there are older screen readers that don't use MSAA. So there is a requirement to do both.
GR: There is also an I18N lag with MSAA.
IJ: It seems new to me that we are requiring redundant output.
RS: Suppose I'm writing a custom button that has it's own window class. To be accessible to an AT that doesn't support MSAA for the custom component, you have to use std API so that the AT can get the information. Another example: Suppose that you're Mozilla, designed for cross platform. For that reason, you don't support MSAA and need to draw text to the screen (until you support the DOM...).
MN: I don't think you need to get into details about which a developer needs to use. I agree with the reviewer: the UA should be able to conform by providing info through either one API or the other.
RS: If there's an engineered API (e.g., MSAA) you should use that API and ensure that it works. And if this is more accessible, this should take precedence over drawing to the screen.
MN: I see 5.5 as a special case of 2.1.
RS: For output, you should implement MSAA or the DOM first (if applicable). If they don't apply, draw text to the screen.
IJ: Add a note to checkpoint 1.2 that says "When available, it is preferable to use the APIs discussed in G5 instead of using standard device APIs directly."
CMN: It's more preferable to use both directly. If you use MSAA or the DOM and then you also rasterize a picture, then you need to use std APIs.
IJ: I have heard:
RS: In JAVA 2, you have to use the accessibility APIs.
Resolved: No change.
Action IJ: Add a cross reference to guideline 5. In techniques, discuss advantages of doing both.
JG: Is "zoom" the right term.
CMN: In HTML and CSS, you can increase the font size and text reflows nicely. And the reviewer's comment is true. In SVG, you get no reflow when the font size it changed: text may overlap when the text is resized, so zoom is the preferred technique in this case.
JG: "Zoom" in one context can mean to take one pixel and make it four pixels.
IJ: I think that "zoom" must means go in and out.
HR: I don't think that "zoom" is an adequate term.
CMN: Some user agents rescale and reflow as their zoom.
HB: I think that magnify and reflow and one of the most important accessibility techniques for someone with low vision.
MQ: We want to be able to make content more accessible, and word wrap is important to this.
Resolved: No change.
Action IJ: In techniques document, discuss what CMN has been discussing. Just changing font size may obscure information and scaling would be better. Reflowing (e.g., word wrap) is a good thing to do and should be discussed in techniques.
Various pieces required:
CMN: If the keyboard is a standard input API for your system, you have to use it.
JG: I think we resolved that you don't have to support all standard APIs.
CMN: I'm not sure I agree. Depends on the meaning of "standard".
Proposed:
CMN: I think the UA should support all standard APIs for the operating system. It's not sufficient to expect support for a subset of them.
JG: The WG has already agreed that this is an undue burden - I don't have to support the bar code reader API.
CMN: If the standard API allows you just to dump a rasterized image to the screen, does this suffice? This does not make the information accessible to ATs.
IJ: I don't see how the misuse of an API is resolved by requiring the use of more APIs.
GR: We need to (a) highlight in the text of the guideline that user agents should use higher level routines.
RS: In Windows, you would use "textout" or "exttextout" to draw text...
JG: CMN, do you want UAs to draw information more than one way to the screen?
CMN: I want one standard API that does the redundant work for you (and so that you don't have to draw manually through the other API).
RS: If you use MFC or visual basic, you should ensure that those libraries default to the standard system API for drawing text.
CMN: You could imagine a system where there is a keyboard API and a generic text input API.
Proposed:
GR: I think this should be in the prose.
CMN Proposes: Delete "device" from 1.1 and 1.2. The question remains - if you use a good programming language, it will automatically put your information through the standard device APIs. "Use the standard input and output APIs for the operating system."
IJ: What's the scope of "input and output"? Does this include port 80 for HTTP? The "stdout" on Unix?
IJ Questions:
CMN: Redundancy only required when information isn't propagated by the API to others.
CMN: This has been answered by MN and HR. MSAA may not be the best way to get access.
JG: Where do you stop? Infrared access? Writing to disk?
CMN: On most systems, redirect is automatic.
RS: You could say "for those devices that allow the user to interact with the system."
CMN: You can push info around through MSAA. But if you put it into MSAA, it gets propagated.
HR: You don't have to give all functionality to the user through the voice API. You do through the keyboard.
Resolved:
- Point out that APIs should be used appropriately - use the text API for text, don't use the graphical API.
- Point out that people should not work around standard APIs.
- Point out that there may be preferences in APIs (e.g., use more abstract over lower-level, but ensure that information reaches lower-level APIs).
JG: Conformance does not *necessarily* guarantee accessibility (and non-conformance doesn't guarantee inaccessibility). Refer to last call issue.
CMN: In 5.5, we guarantee programmatic access. This means you can run whatever device you want.
CMN: Max (Nakane) has a telephone that he uses to access the Web. But the output mode is through the screen, and that's all. The phone doesn't export anything as far as I know.
IJ: Consider for this case, a kiosk that doesn't allow you to plug into it (Guideline 5 drops) or a handheld device that has limited RAM (no room for other software, or it's not a multitasking system).
MQ: This means no mobile device can conform to these guidelines.
CMN: If you have just speech output, or just keyboard input, and hardwired programming and no way in, you can claim that 5.5 doesn't apply. This means that inaccessible device could comply.
IJ: I consider dropping this clause of the applicability provision a significant change to the guidelines.
CMN: As do I.
HR: I don't think it's not conforming then - we want the devices to meet as many checkpoints as they can.
GR: The way the current conformance statement is stated, those considered inapplicable must be stated up front. Consumers/Purchases/Regulators can establish whether it meets their particular needs.
CMN: Conformance is not the end-all of the accessibility of the tool.
IJ: I still think that hardward and software limitations affect the range of configurability (e.g., colors, fonts).
RS: We don't need to delete the provision since we are not really addressing mobile devices. More work needs to be done.
JG: Do people understand that the current applicability provision means that for any mobile device that doesn't allow communication with other devices means that Guideline 5 doesn't apply?
/* Everyone agrees */
JG: How many feel the document should become a Recomendation this way?
HB: I would like to make it explicit that we are excluding devices.
JG: We do not have guidelines for a user agent that does "everything". We can always find some group that doesn't have access, so we require communication of content and user interface (interoperability). We've already discussed "stand-alone" conformance.
CMN: I don't think the guidelines should become a Rec with the current provision about hardware limitations.
Resolved:
IJ: Two parts
CMN: I think that number 2. is very important. The Director has said that the Recommendation (the guidelines) must be able to stand on its own - you must be able to derive what's required for conformance.
Action JG: Identify the minimal requirement for each checkpoint.
Resolved: Adopt proposal
Action IJ: Add statement up front that everything through UI except where stated that through API or both.
Resolved: No change. Using OS features is a good thing, but must be accessible.
Resolved: Editorial.
Action IJ: Propose changed second sentence of 1.1 to the list.
Resolved: The intent is indeed support for every supported input device. No change.
/* EH joins */
CMN: As we've discussed at length today, there are a lot of operating system conventions for accessibility (e.g., standard APIs). There's nothing in the guidelines that says "don't provide a better installation setup." The Guidelines do say "use the standards since some device you didn't think of may not be able to use it.
EH: Need to clarify what the accessibility settings are. Are we the judges about what the conventions are?
IJ: We refer to system guidelines for accessibility. I propose:
JG: For users with screen magnifiers, context-sensitive access important.
GR: Two-dimensional tables rely on understanding relationships expressed through layout.
CMN: I've argued in the past that the "standard" graphical rendering of a table in two-dimensional layout is a sufficient technique for making clear the relationship among table cells.
Resolved:
Action CMN: Propose a technique that explains how serialization plus navigation would suffice.
CMN: Users have access to the text according to 2.5 (being able to select alternatives). Thus no changes required to provide what he's asking for.
EH: The definition of alternative equivalent does make a distinction between primary and alternative content. A strict reading of the term "equivalent alternative" would mean that the image wouldn't count.
IJ: Have we heard that images are distracting to users with CD? If not, why is this checkpoint here?
EH: Images may also bother users with low vision (who may be distracted).
EH: Up to this point, people I've spoken to would distinguish between CD and learning disabilities.
Action IJ: Ask reviewer for more data.
IJ: It is disorienting for users with CD, or who are blind or accessing information serially. I can see that it doesn't prevent access to content, however, it may make it near impossible for some users (e.g., with short-term memory problems) to locate where they were.
JG: At some point, inconvenience makes something unusable.
RS: Very large documents are a P1 problem.
Resolved: No change.
/* EH leaves */
Resolved: This is covered by structure navigation.
CMN: The WG intentionally did not choose a relative priority rating for this and other checkpoints related to Web content. In this case, knowing the feature is there is critical to being able to learn to use the tool.
Resolved: This is critical for using the tool. No change.
Resolved: Editorial. Adopt suggestion.
Resolved:
Resolved: Editorial
Action IJ: Clarify the usage of "checkpoints for content accessibility", notably in G2.
Resolved: This is covered by the structured navigation requirement
Resolved: Editorial
Action IJ: Clarify checkpoint wording:
For graphical user interfaces, allow the user to configure the arrangement of user interface controls.
Resolved: Editorial.
Action IJ: Verify how it's used in the document. If not used, moved to techniques. Or move to glossary. Or replicate in glossary.
Resolved: Editorial.
Action IJ: In that paragraph, move usability and accessibility to the sentences about consistency.
Resolved: Editorial. No change.
/* Adjourned 15:40 EDT */