Chair: Jon Gunderson
Date: October 25-26th, 1998
Location: Minneapolis, MN, U.S.A
Time: 9:00am-12:00pm morning session and 1:00pm-5:00pm
for afternoon session on both days
This adgenda based on the current status of the user agent working draft. The agenda may change based on the issues raised, dicsussed and/or resolved in the working group between now and the face-to-face meeting. Members of the working group will be informed of changes to the agenda and agenda changes will be posted to this document.
9:00 - 9:15 Jon Gunderson, Chair UA working group
9:15 - 9:30 Judy Brewer, W3C/WAI/IPO Director
9:30 - 10:30 Presentation adjustability and HTML Compatibility
10:30-10:45 Break
10:45-12:00 HTML 4.0, CSS1 and CSS2 compatibility
12:00 - 13:00 Lunch
13:00-13:30 Images and object rendering
13:30 - 14:45 Keyboard navigation of documents and alternative views
14:45 - 15:00 Break
15:00 - 16:30 Table orientation, rendering and navigation
16:30 - 17:30 Frame orientation, rendering and navigation
9:00 - 10:30 Dynamic HTML event identification and emulation
10:30 - 10:45 Break
10:45 - 11:30 Dynamic HTML event identification and emulation
11:30 - 12:00 Document Object Model (DOM) and compatibility with third party assistive technology
12:00 - 13:00 Lunch
13:00 - 15:00 DOM and compatibility with third party assistive technology
15:00 - 15:15 Break
15:15 - 16:00 Visibility of accessibility features and documentation issues
16:00 - 16:45 SMIL and MathML user agent accessibility
16:45 - 17:00 Statement and review of action items for working draft and working group
/* Meeting began at 9am */
/* Meeting participants and agenda */
/* On WAI and W3C Recommendation process */
/* Review of design choices motivating current structure. */
DC: How can we ensure that the guidelines are actually implemented.
JG: Fewer Priority 1 means more chance they will be implemented
KH: We're not getting much feedback that IE is inaccessible for certain of these topics. Need to review Pri 1 status of some guidelines.
Judy: Change "impossible" in Priority 1 to "very difficult or impossible". Wendy should also take question of wording to GL WG.
/* Issue of what should be implemented directly by the UA and what should be enabled through an API. */
KH: Guidelines not specific enough about who should do what.
KC: Careful: if you put the burden on a specific entity, you will make others think they do not have a responsibility and they will drop out.
WAC: Might want to ask UA developers to cover the bases. If they can't/won't develop a certain technology, do research/provide information about how it can be done.
JB: Concern about defining obligations at a fixed point in time (rapid changes likely). Also, current document defines types of technologies or assistive technologies too narrowly. Yes, dilemma exists, but solution may not be in assigning roles to different groups.
DC: Stress universal design.
WAC: (second try) By default, responsibility on UA developers. If they choose to/can't follow a guideline, see to it that other parties can satisfy it.
KC: If something is Pri 1, then should be responsibility of UA to incorporate it without need for assistive technology.
CO: About everything can be implemented by assistive technology. So a question of division of labor. Current document doesn't currently address this.
JG: Financial burden also an issue (e.g., cost of a screen reader).
KC: Also assumes portability of assistive technology. Assumption is people at a desk. But I walk around.
CO: Yes, but we must scope this document. If we try to address every application or technology, we'll never finish.
DC: If a UA can't provide a service, provide a connection to the service at the same price. UA vendors should document what needs to be done.
JG (to CO): Do you have any ideas about where the division (of labor) should be made?
CO (off the top of his head): In browser: keyboard access and control of presentation. In assistive technology: table navigation, speech and braille output.
HR: Perhaps broaden definition of UA to "program or set of programs." Perhaps these guidelines don't need to make the distinction between "primary" and "assistive" programs.
WAC: Not all desktop systems have keyboards. Saying a tool must allow keyboard navigation limits the scope.
CO: Beware of expanding document to cover everything becomes a universal design document, not a UA guidelines document.
WAC: Be general in the right way. Don't say keyboard. Say "not pointing device".
JG: There is life after this document, can address other issues later.
JB: Definitely life after group - support for guidelines/specifications is a growing W3C concern.
CO: Proposed. Several documents: PC-based UA, multimedia technologies. Trying to address primary concerns of each technology first.
JB: I'm not sure this would speed things up. For each technology, would require convening a group, etc. Also, not so sure that the technologies as far apart as that.
IJ: Perhaps useful as model, however. Extension of dependent/independent UA split.
JG: (Summing up): First priority is universal design is built-in. Second is make possible to assistive technology.
KC: Perhaps reflects consensus, but not my point of view. If a priority 1, must be implemented by UA directly.
HR: We don't have a definition of assistive technology.
/* Ian points out that guidelines are missing priorities in this document */
CO: I'd like to see guidelines that are lists broken down into individual techniques (e.g., color AND font AND selection, etc.).
DC: I agree with Chuck based on experience with PAGL. Need to be able to say "yes/no" for compliance.
CO: General process observation. I would like to get closure in this meeting, and avoid deferring to the mailing list.
IJ: Are all guidelines Priority 1? That means that there are 15 priority 1 guidelines?
CO: Too many.
JB: Advantage to breaking these down.
KC: Size matters. If you break it into pieces, will end up with a number of priority one's. Tricky to figure out how to draw the line.
CO: Checklist is important to take to developers. A more detailed complete checklist is more effective for the purpose of taking to developers.
WAC: (Suggestion of division into Pri 1/2).
KB: Total number of guidelines implemented less important than the needs of a specific group and whether they are satisfied.
DC: The current document is blind-centric. E.g., navigation with command keys. We say nothing about the simplest command key possible, mnemonics where possible. Ensure that wording of guidelines is general enough.
WAC: One justification for guideline rating vs. techniques is that to satisfy a guideline, you must implement the priority one techniques of that guideline.
HR: I have difficulty with this point.
KC: We must be detailed, but also brave and quick. Not just a question of disability.
IJ: Attempt to summarize Priority one criteria: a) Either satisfies a large percentage of the population or b) meets the acute needs of a smaller percentage of the population.
JG: What do we gain by rating the guidelines?
WAC: In PAGL, we limited ourselves to 19 guidelines: 6 Pri 1, 7 Pri 2, 6 Pri 3. We rate the techniques as well. A technique cannot have a higher priority than a guideline. (Ian is surprised. Thought possible to have a Pri 1 technique for a Pri 3 guideline).
DC: Careful, the techniques are not yes/no (they are multiple or subjective).
JB: How general are some of the guidelines? Some are collections of things (e.g., use "features", etc.)
WAC: Goal was to give several layers, so that people could choose their level of commitment.
KH: Ratings are important. I may ignore the Priority 2 since there may be lots of Pri 1. Also, if I satisfy 3 of 5 Pri 1 techniques, have I satisfied the guideline?
HR: Focus here should be on satisfying guidelines that help the community, not marketing issues, etc.
KH/CO: Marketing cannot be ignored.
DC: Problem is that the techniques are not parallel.
JB: Taxonomy is important. Will be used by agencies as well.
KC: Taxonomical complexity that we can avoid. One thing that would be most important for the largest population would be controlling font size. Is this a guideline or a technique?
IJ (to KC): A guideline (since no language-specific information).
HR: Yes, will be used as a marketing club. We must consider how this document will be used as an assessment. This document should contain information about how it is intended to be used.
CO: I want to downplay marketing issue and "up-play" taking guidelines/checklist to developers.
HB: Checklist should be yes/no. Dave's point is that some of these may not be able to be translated into yes/no.
JB: The working group is chartered to produce guidelines. I urge you not to stray from the path of producing guidelines. They may be translated into a checklist.
CO: Everything should be yes/no. Where they are not, effort should be made to clarify how they can be made yes/no.
Note. In the following sections, we refer to techniques as numbered in the 19 October 1998 draft of the User Agent guidelines (UAGL). However, almost all of them were deemed to be "guidelines" pursuant to the dicussion at this meeting.
Section 4.1: Allow the user to control document styles.
Should this single guideline be broken down into several?
IJ: These are general, should be guidelines, not techniques.
WAC: Yes, doing with style sheets is one technique, if CSS supported.
Action: Ian, Jon, Kevin, KH will take section 4.1 and work into a prototype that reflects the discussion up to this point. Will bring back to the group after lunch.
/* Break */
/* CL: Need to work on definition of dependent/independent user agent */
/* CD: Need to make language less vision-centric */
/* JB: Please review document with a wide range of disabilities in mind and get review *quickly* from specialists in different areas */
/* JG: Add audio access to 4.1 */
Section 4.2: Provide access to alternative content
/* Discussion of alt/title/longdesc. */
/* CL: HomePage Reader supports longdesc */
/* JB: Does Opera (beta) support it */
CO: All attribute values available through the API
JA: Users should be able to turn off alt information rendering (since it may be confusing).
CO: I have thought that CSS should have an attribute for controlling tool tips.
KC: Simplified screen (take the junk out).
JA: Jaws for Windows (JFW) can serialize the screen. Having information spread all over can be distracting.
JG: We don't have a guideline about serializing the page today.
CO: E.g. today in Win 95 - high contrast flag. IE versions 3 and 4 change style according to this flag.
JG: We have a section on user profiles.
WAC: A lot of people want to get rid of advertising.
/* AdExtinguisher gets rid of advertising. Acts like a proxy. Gets HTML before it hits your browser. Uses a database. */
IJ: Should 4.2.1 be Priority 1?
JB: Why doesn't the document use the expression "alternative representation of content"? (See language in previous draft, the Aug 16 draft).
JG: Priority 1 for alternative representation of content for images.
WAC: Move 4.2.1 to rationale section.
JB: Fragment into different types of objects to address: images, multimedia presentations, audio files, animations, applets.
JB: What's the most effective way to treat multimedia? There aren't multimedia objects; there are video and sound objects.
WAC: In PAGL, There are four guidelines (alt for static images and programmatic objects, long descs for images and programmatic objects, audio, things with their own interfaces)
JB: But ensure that text media objects (when there are several) be able to announce itself. But PAGL framework sounds like good start.
/* Need to establish framework be for organizing the guidelines */
HB: We may end up with a lot more priority one's, but they will be much more specific.
JA: The guidelines cascade. Things that have their own interfaces should be accessible. E.g., real audio tool. But that is a user agent, so should take into account these guidelines.
JB: If a tool is a plug-in, should be able to pass through preferences, use OS flags, etc.
KC: Multimedia should be thought of not as some obscure activity. It's "watching TV".
(About 4.2.1)
KC: Good technique is to link to a place where you can find information. E.g., you could link to the Louvre if you want a description of the Mona Lisa.
IJ: What if you're not online.
KC: Problem is that authors who are not good at describing things are doing work that people who are good or who have done already, should do.
WAC: Let users access alternative information based on media types. UA could choose which media type of alternative content based on, e.g., "type" attribute.
Section 4.2.2: Render alternative representations in place of primary.
IJ: What is realistic to expect from the UA here? Rendering alt text and an image simultaneously? One or the other? The ability to render in-line or in an external viewport?
JG: Potentially several alternative representations. Give user ability to manage them.
KC: Visually-impaired people may want both alt text and the image. They typically operate in a multimedia environment, scrutinizing the visual information, assisted by the alt text.
WAC: Might want to use the alt text as a caption for an image.
JG: Selection/replacement feature very important. Simultaneous access also very useful.
WAC: Might help frame discussion by defining user profiles (for UA developers).
JB: Scenarios under development in EO WG. Difficult to make this good and useful. Needs input from the three WGs
/* Mention of "Webmonkey" and "Squishy" here. */
JB: Does Squishy have some scenarios, or just tell you to develop them?
Action WAC: Send URI to Squishy to UA mailing list.
JG: Two concepts - replacement and simultaneous access.
/* Judy, Kitch, Jim, DC, CL, Joe will work on describing control of alternative representations */
Section 4.2.3: When no alternative text representation is available, indicate what type of object is present.
KH: Why is this a priority 1?
DC: Where do the PAGL and UAGL overlap? Do they overlap here?
CO: IE currently has a small icon for images. Does this comply?
JA: Is there a text indication?
WAC: Doesn't need to be priority 1 since telling people that information isn't there won't prevent them from using the page.
KC: But what if there's one image and only one image on the page?
ST: My problem with this discussion is that I want all of this information.
CL: Are these all images or just images in links? In our browser, if there is no alt text, we display some of the URL. If there's not link, not sure what to do.
KH: We expose that something is an image through an API.
EH: I find full URL to be overload of information.
CL: We only render the last part of the URL.
KC: First and foremost, I need to know that there's a link, not that there's an image.
HR: If it's a link, the URL will appear in the status line.
/* Lunch */
/* The following is the proposed restructuring of 4.2 based on lunchtime discussion */
Note. Control here means user wins.
/* The issue of finer grain guidelines vs. too many guidelines was discussed. The editors will strive to expand guidelines appropriately while keeping numbers as low as possible. */
/* KC: Four characteristics that should be controllable: Highlight, position, intensity, context */
/* Push next three guidelines to configurability and visibility */
/*End of proposed restructuring of guidelines. Techniques not discussed yet. */
IJ: What do techniques mean in this document? How to distinguish between implementation and technique (e.g., for font size: use CSS. But don't say that user agent must open a window to allow this)
JA: Technique: Use CSS/Dialog for input/ Allow pass-through of system settings (e.g., OS flags).
JG: And also say that author styles are overridden.
JG: Is there consensus that this format is usable?
KH: Concern that this will become a 25-page document. I see the need for a checklist. I also see the need for grouping/abbreviations.
JG: A "principles" document could be created for an executive summary.
WAC: We discussed this in PAGL. We decided that content was more important than document structure in a face-to-face meeting.
JG: Action item on group to come up with techniques to see if that level works.
WAC (To vendors): Please give us scenarios you have encountered that you need supporting documentation for and we'll try to engineer them to fit those needs.
CO: Developers need to know priorities. They ask "Why?" "How important is this?".
KC: Perhaps priority depends on importance of content.
IJ: PAGL has this wording.
JB: You need the capability in UA because you don't know a priori about the importance of the content.
WAC: Developers needs a small amount of information to not be overwhelmed, but the degree of overwhelming them depends also on their experience.
/* No discussion from group assigned to review Section 4.2 during lunch */
/* Back to discussion of 4.2.3 */
Section 4.2.3: If there is no alt text, indicate type of object.
KC: Before that, can we address the issue of whether UA should be able to render alternative content at the same time as primary content (instead of simply in place of).
JA: How to indicate to the user that a long description is present?
IJ: Sounds like a technique. Same issue arises when indicating the presence of scripts.
CO: (for longdesc, image not shown)
IJ: What's a context menu (right click menu)?
CO: Right-click in Windows world.
WAC: The abstraction is a query mechanism to find out more information about an object.
CO: The properties page. Also, power toys allow me to zoom in/out.
DC: Suppose you have images turned on. How do you that a longdesc exists.
CO: Border? No, authors wouldn't like it. Synthesize D-link (yikes)? Different cursor? Alt text with brackets? This is implementation specific.
JG: So: When image is rendered, provide a visual indication that long description present. Can you do this with CSS?
IJ: Yes.
Section 4.2.4: Allow users to hide the display of D-links used to provide access to long description information [Pri 3].
JB: Note that "D-Link" is trademarked.
KH: How does user agent know what a D-link is?
/* Push back to PAGL? */
DC: PAGL are for now. UA guidelines are for next generation user agents. Should be assumed that they will implement new features at that time.
JB: How to deal with interim situation?
WAC: Do both today. So what does UA do in future.
KH: Page authors work daily. UA vendors produce every 6 months to a year.
IJ: Proposed
KB: Why is duplication of d-links a bad thing?
JB: Designers don't like displaying "[d]" everywhere.
WAC: EO should address converting d-link to "longdesc". Also, don't use "class", use "rel" to identify links.
CO: I think this should be worked on in the PAGL. If legacy pages are the issue, there may not be enough of them to convince developers to deal with the problem.
DC: I agree with Kathy. How, in the future, do you require UAs to reformat tables as style information.
IJ: 'rel' attribute discussion dropped if UAs don't have to do things automatically.
HB: What constraints, if any, are placed on class?
IJ: None. Idea would be that authors write special style sheet to hide dlinks. User should be allowed to select from alternative style sheets.
Resolved: Drop 4.2.4!
/* JB: No multimedia objects. Video, audio instead */
Section 4.2.1(multimedia): Allow the user to identify and turn on/off text captions of audio.
WAC: What does "identify" mean?
JB: Deaf/blind people need to identify (or their assistive tech does).
IJ: Sounds just like identifying presence of "longdesc".
JA: Must be revealed either to user or user's accessibility agent.
JG: Sounds like two guidelines:
MP: Important to be able to turn off since potential conflicts between synthesizers and multimedia events.
ST: Aren't conflicts with synthesizers gone now?
MP: Some sound cards still have problems.
KC: Lift the concept of identify.
JB: It's not common sense enough, unfortunately. It's worth saying explicitly. Distinguish "identification" from "visibility" from "configurability".
HR: User profile might also identify what user wants to identify. E.g., I may be able to identify sound easily, therefore don't need help from UA.
JA: Pass-through of system flags important here.
JA: Charles Silverman has done a lot of work with captions - "Multimedia captions". Two videos running simultaneously (one of text).
DC: Complementary vs. supplementary information. Direct translation vs. additive interpretation.
JA: Text captions in video form still not accessible to deaf-blind. Therefore the site would not be considered accessible.
KC: We must therefore define Captions to be text captions.
JB: Make sure Charles (Silverman) knows about the work of this WG and knows that the effort to create caption not be in vain and that the information be convertible to text.
/* For PAGL JB: Maybe we should say that if alternative formats are used, they must be convertible to standard formats */
KC: Text in non-text formats will become a big issue as digital photography becomes domestic.
HB: What text caption are we talking about?
WAC: We avoid the word caption in PAGL and use the term "textual equivalent" instead.
Action Judy: New caption technologies are becoming available. Concern about accessibility of these technologies. What groups should be tracking these?
Action editors: UAGL will use term "textual equivalent" rather than caption.
WAC: In PAGL - where sound played automatically, provide visual notification. We would like UAs to provide this visual notification.
JB: Is this "showsound"?
CO: "Showsounds" (Win NT in particular). Also want to do the following: If UA knows a sound is being played, show this info on the status bar. Allow user to pause or replay the sound. {References to "bgsound" attribute, an MS extension.} Several mechanisms: flash window, flash screen, show in title bar.
WAC: Is it possible for UAs to know that background sounds are played (either CSS, MS HTML, or Java) so author doesn't have to indicate it?
IJ: Treat this like BLINK element: have a guideline that says when UA recognizes sound, provide notification.
JA: Pass-through to OS necessary again.
JG: But new user agents may not have NT system flags, so still need a guideline.
DC: Distinguish UA, assistive technology, OS.
JB: There is a continuum of different types of user agents.
/ * Break */
Section 4.2.2(multimedia): Integrate section on captions with other style control.
JA: Remind people that multimedia players are still user agents.
JG: We can create indexes that organize guidelines according to type of UA.
DC: Note that the UA rendering one media type might not be the UA rendering another media type.
IJ: Again, the issue of being able to support a certain media type. Is a UA responsible only for those media types you support?
/* Proposed addition to document: Add appendix information summarizing guidelines/ technologies for specific devices */
CO: Note, in the case of SAMI, source of caption may be entirely different.
HB: There are a number of synchronization issues among players. User wants to control pace for rendering things.
JB: Identification vs. rendering. Hard to assign responsibility for rendering since you don't know how user will make use of alternative content. In some cases, player / browser may just need to identify for assistive technology that something is present.
JG: "Primary" UA first level of responsibility for alternative renderings. But when impractical/impossible, UA must expose information for assistive technologies.
MP: Information given to assistive technology software transmitted in a common format.
Section 4.2.3(multimedia): Allow the user to identify and turn on/off audio descriptions of video. [Pri 1].
/* Editors: Add "identify, select tracks, and turn on/off" or some such wording. */
HB: You may have multiple audio descriptions and must be able to select from among them.
/* Editors - add language about how importance of content affects importance of guidelines */
Section 4.2.4(multimedia): Ensure that text media objects may be identified by third-party assistive technologies.
Define "text media objects" (SMIL) to be captions.
Ian Proposes: Top-level sections on "identification", "visibility", "notification", "configuration", "querying" (and in general, different headers for guidelines document and HTML subject-based organization for techniques document).
/* Discussion here turned to compatibility issues then back to multimedia issues. For continuity, the section on compatibility has been moved forward in the minutes and the multimedia discussion has been unified */
Section 4.2.5(multimedia): Make accessibility-related information from the OS user profile available to the media player.
JG: Fold this guideline into another guideline (about pass-through feature).
Section 4.2.6(multimedia): Allow users to reposition captions.
JB: (rationale) Author may not realize that captions may be obscuring some key visual information.
IJ: Generalize this? Allow users to position content when there's overlap? (e.g., when a huge font is being used.)
KC: Helpful for people with cognitive disabilities to be able to drag distracting content out of the way.
JB: How much of a problem is this?
MP: We let you strip graphics and create a linear reading order. But user can't reposition it.
WAC: E.g., users may want navigation bar at the bottom of a page.
IJ: Is this particular case (captions) so important?
KC: Can't make a pure theoretical decision here about presentation vs. content. I think that requiring positioning is asking too much for a UA compared to the results. There are already ways to reposition. Too costly.
JB: W.r.t. the particular case of captions, I think it's important. Authors don't have much experience with how captions will be used.
WAC: This is an authoring issue. Should the UA correct poor captions?
JB: Not quite an authoring issue, but one of user controlling style.
IJ: Propose pushing it to section on controlling presentation of documents.
Section 4.2.7(multimedia): Push rendering rate to section on controlling presentation.
WAC: Want to generalize to video as well. Also, include "pause" as well.
/* General features for sound/video: stop, start, pause, rewind, fast forward. */
JA: Do we say anything about maintaining synchronization?
JB: I would mention it.
JB: Is the question "What should we be implementing?" being adequately addressed in the current format?
CO: I'd like to see a list of HTML attributes or CSS properties that have accessibility implications.
/* Check out "browsercaps" to see which browsers support which HTML features. But browser caps is currently out of date... */
/* IJ talks about his proposal for documents specific to each language */
JB: I think there should be an implementation section for W3C specs and a compatibility section with non-W3C APIs.
DC: There is a problem of distinguishing elements that are ignored vs those that are displayed differently in different browsers vs those displayed pretty much the same on different browsers.
HB: HTML 4.0 spec not very clear about how #IMPLIED attributes (optional) are to be treated.
/* See sections 8.1 (CSS) and 8.2 (HTML). */
JB: I don't think the compatibility section is sufficiently specific.
IJ: Proposes pushing lists of HTML/CSS features to techniques document. And completing list. Add SMIL (and MathML).
Section 4.2.1(objects): Allow the user to specify that alternatives to a script be rendered (e.g., in HTML, the content of NOSCRIPT).
DC: What do you do in the header (HEAD) with NOSCRIPT.
IJ: No NOSCRIPT in the head since no rendering in the HEAD.
HB: What about OBJECT in the head (fallback context.)
IJ: Hmm, I'll have to look at HTML spec.
/* Scribe found the following sentence in the HTML 4.0 specification: "Authors should not include content in OBJECT elements that appear in the HEAD element." */
WAC: Any way to cascade scripts? (User scripts take precedence over author scripts)?
IJ: Work currently going on in CSS WG for specifying how scripts may be bound to elements (instead of specifying them within element start tags). This mechanism may include cascading.
IJ: Guidelines don't say "Allow users to turn off scripts." I propose adding this guideline. (Note: HTML doesn't require NOSCRIPT when scripts are off.)
CO: Let's make NOSCRIPT useful.
WAC: Notify users of changes due to scripts. Allow user to specify the rate with which the page is updated. (Users may need changes to occur slowly to process them.) Applies to scripting and HTML redirects. Today, onus on authors. Would like UAs to provide some control as well.
HR: Rate should be controllable (to make certain things accessible). But some things rely on refresh rate.
KC: Lots of information (e.g. Dow Jones) is not controlled by an author. Must rely on UA for control.
CO: (On page refresh). Refresh could be disabled, but you couldn't adjust the timing (since depends on author).
/* Editor: Does redirect belong in style section? */
JA: How is this different from stopping marquis, blink, etc.?
Summary of UA tasks with respect to scripts:
Action Wendy: How does UA identify page refresh? What needs to be done. Discuss in PAGL.
Section 4.2.2(objects): Allow the user to specify that alternatives to a frame be rendered (e.g., in HTML, the content of NOFRAMES).
WAC: If people don't want to load frames, do we at least want to present frame titles?
KC: Problem is not screen readers, but authors not specifying a sequence of frames.
MP: With JFW, you can tell when you move to a new frame. Also, IE allows you to move from one frame to another. Frames are not so inaccessible to us.
CO: I agree with MP. No difference between frames and multiple windows (screen readers can recognize separate windows). Problem is that framed sites are typically poorly-designed sites (for example of accessible frames, see HotMail). Screenreader technology not up-to-date yet.
DC:
JB: Problem with frames is navigability; when content changes, you can't go "back" with the back arrow. (Navigation issue)
DC: I agree. When the main window of a frameset is not the primary window, there is an extra step of selecting the main frame window prior to scrolling.
EH: Jaws for Windows allows people to arrange frames in a list view and select an individual frame. Is this an authoring issue? Seems to be more of a third-party issue. Where do UAs fit in?
JB: Many issues shared between different WAI WGs. Might be priority 2 or 3 issues.
WAC: PAGL says that all frames should have titles (to create lists of frames, Priority 1). Associations between frames should also be described (Priority 2) Provide NOFRAMES (Priority 1).
WC: The functionality offered by Jaws as described by EH are not currently being shipped.
KC: If author's intentions are unclear, UA probably can't make sense of them.
DC: Screen readers may have work-arounds, but not everyone has a screen reader.
JB: There's a barrier to navigation. UA must provide extra help for cases when author does a poor job.
JB: Method for navigating rendered frames must be more obvious.
HR: Must be able to identify frames....
JB: In identification section, must clearly distinguish identification to a) User agent and b) User.
CL: We use "title" on FRAME to give frame titles.
WAC: So does Lynx.
JG: UA must be able to deal with "title" and "longdesc".
/* Editor: Technique for identifying frame names: first title, then name */
/* Discussion of "longdesc" for Frames */
JB: If we deal with navigation and identification, do we need anything else?
WAC: Some screen readers just read across the screen (mixing content from different frames, like for tables).
EH: Often, when in a page with frames, when you "go back", the whole page is redrawn, so no way to back.
/* Ian talks about limitations of frames, notably that no URI can designate current state when frame content changes and "back" functionality offered by UAs fails today. */
WAC: "Open current frame in window" is an important feature for that reason. Need to bookmark individual frames.
KH: IE 5 handles this problem to a certain extent (but can't talk about that right now...)
JG: Keyboard navigation of frames, maintaining focus in frame history, presentation of frameset information (this would be a technique).
/* Ian and Wendy mention some agenda items they would like to add/deal with in these meetings */
/* Began 8:30 am */
Some issues:
Current recommendation: If table used for layout, serialize by column. Allow row or column order serialization
For data tables, allow rendering of header information prior to reading the cell content.
For keyboard navigation, move point of regard from cell to cell, beginning or end of table, orientation information.
HB: Much richer set of descriptions available for describing cells. A cell (in a data table) can be described by the implicit row and column headers. In HTML 4.0, a list of axes can be described. Multiple headers can apply.
Question: How does a UA recognize data tables from layout tables?
WAC: On author end, there have been suggestions for marking up tables to identify them as data tables.
JG: Simplest algorithm today is to look for header information. Also, try using first row or column as header info.
WAC: Don't forget HTML 4.0 table algorithm for finding header information. (See the HTML 4.0 Recommendation, Section 11.4.3.)
CL: There are a lot of pages that use whole tables for single cells of information.
Section 4.3.1: Allow users to specify that tables be formatted serially, based on the type of information in the table.
For 4.3.1: Should user agent try to detect function of table automatically? Or should user be allowed to switch.
CO: I want to push back this guideline (change priority). It requires a lot of work, and I'm not certain that it's necessary (especially since assistive technologies can deal with this). Info is programmatically available and has been used by screen readers for two years (approx.) Probably won't happen as a Priority 1.
DC: I was going to say the same thing as Chuck. (That's the scary thing!) However, the UA must provide hooks for assistive technology.
IJ: Make hooks Priority 1, rendering Priority 2.
JG: Is it a Priority 1 that tables be rendered linearly?
HB: Yes.
WAC: If you have navigation, you don't necessarily need linear rendering. Make navigation Priority 1 and drop priority of rendering.
CO: Yes, priority 1 to be able to navigate tables in logical order.
/* With speech, you only really know about current cell. With braille (for non-nested tables), you can get information about the entire row.*/
CL: We read entire row at a time. Could read entire column. We also do nested tables correctly.
JG (to CL): Do you use HTML markup to identify headers?
CL: Yes.
/* CL Said more about "where am I" feature, but scribe missed it */
DC: Would this information be covered in section on implementing HTML 4.0?
JG: Yes. Also, CSS (:before/:after) can be used to insert identifying information (e.g., "Header").
JA: If we expand HTML 4.0 support requirements, must send information to Authoring Tools WG.
CO: Need guideline: UA should use and expose programmatically all elements/attributes for tables. Information may not be used natively (e.g., in "standard" rendering), but must be available.
JA: Information also available for navigation.
JG: Guidelines related to data vs. layout tables.
CL: We try to identify "real" vs. formatting tables. So we scrapped the automation of this identification. We just use header information for navigation.
IJ: I propose letting the user identify table "type" and the user agent furnishing functionality of serialization. The user could request the functionality for a given table.
HB: (On table header attributes: "scope", "headers", "axis" and their benefits to accessibility):
JB: Don't rely on authoring tool vendors any time soon for commitment to supporting changes. Likely to see uneven implementations. Put as much as possible in camp of authors and UAs.
CL: For IBM, we use Web pages a lot for internal tools. We often have very long tables. We would like to maintain header information on the page so that it's available when we scroll.
IJ: THEAD and TFOOT allow this.
CO: Not supported natively in IE yet.
HR: Is there a guideline that header information be available at all times? (e.g., Priority 2).
IJ: Define "header information" (does it come from THEAD, TH, attributes, HTML 4.0 algorithm for finding header information, etc. Need to define where header information comes from. In CSS2, don't forget 'speak-header' property for aural rendering of header information.
WAC: PAGL mention header information to a certain extent.
CL: We read TH wherever it occurs, but for navigation we use "headers" attribute.
WAC: At trace, we have a script to identify header information. When you change column or row, software reads whatever has changed.
HB: Will IE 5 support the HTML 4.0 table model?
/* No answer... */
KH: These UA guidelines won't be supported until IE 6 or later.
CO: What does Lynx do with table attribute information?
/* No clear answer */
JG: (Summary)
JG: (About guidelines organization). Would having a section on "tables" be helpful.
IJ: The next draft of the UAGL will do this.
DC: Don't forget pass-through of system-level options such as sticky-keys.
IJ: Pass through will be discussed in the techniques document.
CO: UA should support underlying system support. But if UA is the underlying system support, how much should be supported?
WAC: Mark Novak has several suggestions. Action Wendy: Send URL to editors where to find this info.
Section 6.1.1: Allow the user to navigate sequentially between links (including elements with long descriptions) or between form controls in the same view.
Section 6.1.2: Allow the user to navigate views (notably those with frame viewports). Navigating into a view makes it the current view.
Section 6.2.1: Allow the user to search for an element in the current document by its text content.
MP: In Jaws for Windows, we allow searching for links based on link text, searching for first letter of link text.
DC: Do we want a guideline to make keyboard commands logical for, e.g., for cognitive disabilities.
CO: This is contentious. I said that keyboard navigation should not break underlying OS model. People flamed me, saying that underlying keyboard models "suck" [sic].
Some ideas: Keyboard navigation should be done with as few keystrokes as possible, as logically as possible, and consistently with other applications.
WC: New models increase learning curve.
IJ: Fuzzy concepts: "as few as possible" or "as logical as possible". We should avoid these in the techniques.
DC: My definition of logical includes complying with underlying OS model.
CO: See suggestions from Bryan Campbell about keystroke organization.
HB: There are i18n issues here at all (what is logical? what is fewest keystrokes?)
KC: Doesn't make real sense to use the word "logical". It's important to list the issues. E.g., do you want keystrokes to follow a numeric pattern. You may want commands to be far apart (motor problems) or close together (orientation problems). Important to identify the issues in the guidelines.
JB: I hadn't heard about "far apart" needs (e.g., you could use a key guard). If you use a concentrated mapping, with option to allow user to reconfigure. You would solve 80% of problems in general case, but allow remapping. Strongly suggest adding a guideline to allow user configuration of keystrokes. Useful for voice input, scanning, single switch.
IJ: Proposes including text about keyboard navigation issues for those topics that are important but too fuzzy to be covered by techniques. (cf. Mark Novak).
Section 6.2.2: Allow the user to search for a link in the current document based on its link text or alt text.
CO: Why?
CL: In our browser, we allow you to navigate any structural element. Also allow you to search for anything.
DC: Isn't this discussion about giving user access to underlying code?
JA: User shouldn't have to query headings. User agent should simply provide the functionality.
HB: Should be allowed to search for attribute values.
IJ: Summary of search axes:
IJ: What combinations should be allowed? What priorities?
WAC: Reminiscent of pattern matching abilities of vi.
KC: Back to how authors author. The way you search depends on how the author organized the document.
WAC: Chicken and egg problem.
HR: Putting all links in one window is just a view of the original document, links only. This is more user agent than author.
KB: Word of caution: will typical user know how to use all these search options if they're there?
CO: Why is it important to be able to search for or navigate to "the sixth header?"
CL: A lot of documents (e.g., research papers) are organized according to headers.
WAC: Lots of people we've dealt with are more interested in navigating headers than tables. If you generate a table of contents, that's fine, but if TOC doesn't exist, headers are a boon.
/* CO conducts poll to find out which of some UAs support header navigation */
DC: In PAGL, we advocate the use of headers for the purpose of navigating. Natural to include in UAGL as well.
KC: I navigate according to the way the author has structured the document. Need for flexibility in navigation.
JA: When I use Word to produce a long document, I use the outline feature a lot. More and more people will be producing pages with that kind of tool.
JB: I've heard request for navigation by structure from a lot of sources. (To CO:) Why did you conduct the poll?
CO:
CO: Proposal: Instead of navigating by keystroke, make use of the other guideline (presenting information in guideline mode). Create a page based on structural elements. Allow navigation between structural view and main view.
WAC: Sounds confusing to me.
WC: Jaws is using an existing browser to do these things. I'm surprised that these navigation tools are not already available in power toys, or plug-ins, for example.
JB: For CO's proposal, concern about focus shifts between windows.
CO: Yes, my proposal would impose additional keystrokes on the user.
JB: Caution when considering division of labor.
HR: Proposed: If you want to search, create a new view. This view may or may not be visible.
KB: Is there consensus that navigating structural elements is a worthwhile feature.
/* Group says yes. */
WAC: Important to distinguish searching from navigating.
/* Break 10:30 */
/* Wendy on minutes */
JG: DHTML more popular, concern for accessibility:
CO: most difficult and/or important
JG: some guidelines to guide development. Need PAGL and AU cooperation. In current UAGL:
6.5 - Allow keyboard nav of elements w/associated scripts.
2 techniques. Also:
5.2 - Provide information when a script is executed.
WC: In JFW, control PC cursor or Jaws cursor, in numpad access either or together/separate, map to one another.
JG: Jaws interprets HTML to find those associated scripts.
?? no
JG: tab to them, context menu, user sees associated event and triggers the event. Implications to PAGL. There isn't a one-to-one correspondence between script and element (event bubbling). Script ID which element clicked on, based on one "huge" script that interpret what happened. In HTML, looks like only one script. Rquire authors to attach scripts to each element.
CO: precedent for this. In Word, OLE style guide says if OE's with particular actions, context menu submenu enumerates actions.
JA: then user has to know that it's there, somehow. Can't use context menu for each element.
/* JG polled participants to see who had worked with scripts. Four people had. */
IJ: establish scope of this issue. limit to what know what can happen w/doc. Scope: what can UA predict where scripts attached (element may be involved in behavior but not directly involved), can't tell what script going to do, what changes to environment have been
JG: unless author provide description
IJ: exception: changes in style through DOM could be identified (except not DOM 1).
JG: Protocols and Formats WG (PFWG) is working with DOM WG on the next DOM levels. If we have requirements we can get that into requirements documents of DOM groups. PFWG - event notification: when events happen on screen how does a third-party get notification. From UA, have different issues.
HB: Any element may have many scripts attached to it.
JR: When mouseover can trigger? tab to links takes to another site.
JG: Onfocus events so when it gets focus, it triggers a script.
JR: Mechanism to get rid of?
JG: Mechanism to turn off scripts. but at University of Illinois, go to library, fill in form, hit enter, reformats input into syntax lang for user sends to library database. if scripts off, have to go through another pg and learn syntax to learn book search feature.
CO: To DOM: "keyboard access" equals "mouse access"
KH: Members of development team working on
CO: Chris Wilson, DOM group, active in accessibility
CL: In homepage reader, can suppress headers. Rich Swartz (on PFWG).
IJ: In HTML, two types of scripts - those executed during document loading, and those triggered by events. Does this distinction inspire any other comments about scripts?
/* No inspiration */
JF: main concern: HTML as programatic interface: if take online quiz download play, use program to submit quiz. people doing today. scripting is easy.
/* CO does a demonstration to show how HTML and CSS and scripts may be used to create applications. In Outlook 98, feature "the organize feature." it's a little funky. it uses HTML throughout. It has keyboard access. everyday new apps at MS using DHTML.
/* IJ: The "exploding cubes" in Outlook look a little like the Cascading Style Sheets logo. CO: it's just a visual effect, no functionality.
JG: Does the interface employ scripting?
CO: Yes, when buttons pressed. disadvantage - no context menu but tab works.
KH: Effect of using HTML controls.
/* Now CO shows a dialog box. The dialog box looks like an ordinary dialog box (it's a Find dialog), but it's actually an HTML form. CO: "If uses MSAA, can point to and..." [At this point the demo crashed.] */
JG: Reuse of rendering components?
KH: Not an issue. AOL uses IE as browser. lots of products that "host" IE and are reusing control.
JA: But if dealing with browsing the Web, not the issue. Outlook is cool, does that affect us getting info off the Web? We can use it in a Web page, use in an application. Shouldn't matter to us.
JG: It's difficult to parse out.
KH: If we solve problem within a browser, then other applications that host browser component will inherit it. So we should filter way through.
JG: Author have explicit event. may only be certain events.
IJ: Proposal: For PAGL, use the "title" attribute to describe the effect of a script for events.
HB: There can be 15 "on" events!
CO: And the title will show up as tooltip
IJ: Whoops, I retract the proposal.
WAC: What good?
JG: If to reveal a block of text. university. italian homework, then have to provide alternative. no author create alternative. authors don't use script.
KC: Unrealistic. they'll use no matter what we say.
WAC: design.
CO: Must be 2 paths. legacy - NOSCRIPT. forward - improvements to DOM, UAs to make scripts that are accessible.
IJ: What does accessible script mean? can you define that so that it is machine detectable?
KC: What is an inaccessible script? what makes it so?
IJ: Question is is the page accessible, rather than individual scripts. provide access to information may be generated or controlled by script. authors author well, UA what should do? access is in pg, can't get into body of script.
DC: I agree with IJ. It's an issue of content rather than, for example, providing access to a drawing program for a person who is blind. provide access to same info not the same way
IJ: From UA, if script makes page inaccessible, turn it off.
DC: Allow author alternative content that can be rendered UA
JA: Library system: does it affect SR or anything? is it important to tell user "we gonna mash your data" user's don't have to know.
JG: Nine out of ten times accessible, however what if navigation to non-control or link elements?
/* Break */
JG: we're continuing our discussion on DHTML
KC: Trying to formulate the problem. it's not all scripts. which scripts is it? it's a class of accessibility problems. avoid all scripts are bad syndrome.
CO: gave an example over lunch of a CD sampler. companies have demo CD (multimedia demo utility). pop in Cd, in comes multimedia, orbs over hover, and other funk-ass behaviors. it may have been written in any number of languages, including DHMLT. all same problems: keyboard access, reduce eye-candy, user interface timings, etc. general user interface guidelines. the app environment doesn't matter, if follow good interface techniques. DOM/DHTML makes it difficult to create accessible things. can the UA do anything about it? might be: synth keyboard access. PFWG improving DOM. we ought to restrict ourselves to how to improve access to DHTML. still responsibility of author and app environment (DHTML/UA) to make as accessible as possible. all talk of scripts, and event-bubbling, don't matter since basics still need to happen (use sys. colors, pause environment, etc.)
/* Waiting for judy and hans */
JG: good identification of issues and summary. we're waiting for JAWs demo. wrapping up DHTML stuff before get into. do we want UA responsible to repair bad DHTML pages?
JA: programatically possible "any time mouseover substitute keyboard command"
CO: that's "keyboard synthesis." trying to solve
KH: haven't solved
keyboard events? WAC yes.
DC: DHTML diff across browser
JA: the UA knows the focus
CO: internal focus: if right-click giving it focus
JG: moving away from DHTML, moving into authoring. its a general access issue. pg should have responsibility (author) therefore authoring need to have DHTML section. is current HTML good enough to create accessible pp. assume rich environment. if use DHTML to creat mm environ, then have to caption, just like streaming. thus if use browser as app interface then author has responsibility. are there things to put in UA to make author job easier? some Eval and repair f(X) to put in UA for authors that don't?
KC: Last one first. those legally required to have accessible pp for others no way to persuade unless tools given make it easier to do rather than not. interim fix other end of pole. although authoring needed, need some fixes at UA end.
JG: so UA should do something?
KC: not clear where solution is between 3rd party and UA. we can't rely on good authors. !for short term.
JG: repair strategy: synthesize keystrokes. author could have included key shortcuts.
KH: we've been trying to solve and do and have difficulty with.
JG: others?
HB: hard to automate deciphering what a script do before do it.
JG: other side: things we recommend to browser to make easier for author to create something more accessible. access to non-link, non-control elements to give an element focus then some DHTML be more accessible.
WAC: support w3c technologies.
JB yes. highlight certain things.
JG support W3C standards related to DHTML (CSS, HTML 4.0, scripting)
JB since DHTML not specific term, single out pieces that are.
DC in the list of most important tasks of implementation, this be in there? would that list take care of this issue? list of HTML elements/attributes to support include these things?
CO: lobby for HTML to include tabindex on all elements
IJ: not sure what HTML group want to cast it as an XML app. not clear when done "we'll also make mods"
WAC: !tabindex but focus
HB: want flavors of tabindex A, AREA, IMPORT, SELECT, BUTTON. all have user interaction supported. if arbitrarily add to all elements, these specific elements be hidden, thus need flavors to gain focus.
CO: onmousedown,...event trigger (onclick, onkeydown, onfocus) then synthesize tabindex, UA give logical ordering
JG: so should do repair strategy - keyboard access to mouse events.
IJ: active elements are x, y, z and those with scripts attached. links, form controls, elements w/longdesc, elements w/onX events
WAC: way events attached to HTML 4 limits creation of accessible apps
JG: want to make sure current structures are implemented. try to provide repair strategy keyboard for mouse events, either sequential or ... assuming limiting to elements with specific mouse events attached. any objections?
IJ: what about ability turn on/off scripts?
JG: already in preferences.
IJ: kevin says may not solve many problems. might hinder inaccessible scripts.
JG: better access with scripts than without ???) . authoring issue.turning off scripts not help access scripts.
KC: - not clear
IJ: my point off topic. another topic.
JG: want sections that deal with CSS< DOM, etc. that support accessible interfaces, and repair strategy for mouse events.
many nodding heads and mmmm-hmmm.s
JG: now that everyone here, JAWs demo. use IE4.01, JAWs 4.32. manip of DOM.
WC: intro. netscape doesn't give the tools to do. release other scripts in next couple of weeks.
CO: this just like taking out elements
DC: when follow a link from a reformatted pg, to new pg.
WC: dfault always come up graphic then reformat. so never does for you.
KB: when first go into frame pg, user get indication of frames?
MP: no
WC: depending, would know it.
Earle - low viz. can see. keystroke allows to identify
WC: if hit ins=f9 pg w/no frames would say "none found"
HR: - downloading not all HTML yet
MP: says, "wait a sec, not done." so can't reformat until pg. totally downloaded.
JG: therefore using W3C standards, all is good.
HR: have UA guidelines in mind when designed?
WC: until Jan, redesigned web site. became much more cognizant of guidelines.
MP: proper conventions always kept in mind. many authors no standards at all, so how deal with? had that in mind as work on.
JG: how facilitate 3rd parties? current: compatibility w/OS access features, another level related to access API (MSAA, Swing's access, etc.). strongly recommend use, but don't discuss what are.
WC: user testing?
JG: general guideline
Kathy - guideline?
KB: not a guideline, but a general principle. should incorporate testing w/end user.
HR: - where does DOM come in?
JG: exposed. no where says use.
HR: DOM desireable way to
/* Ian back to minutes * /
MP: Can the UAWG submit recommendations in general (at any moment) to DOM WG?
IJ: Yes.
KH: Re: putting all things in an accessibility menu. Some things that help accessibility fall more naturally in other menus.
KB: Yes (many things can affect accessibility). However, you should provide a central point that lets users know where other features can be found.
IJ: Is duplication of entry points a problem?
KH: It's not easy. Newer interfaces will be simpler, fewer.
DC: I agree with Kathy. Don't separate "accessibility", integrate it!
HR: Some accessibility features are implemented in the environment, but not the UA itself.
KB: Yes, redundancy may be confusing. Move accessible documentation to Priority 1, this way the accessibility "view" is less important.
/* Eds. Remove fuzzy language like "direct" and "easy". */
KH: I can "easily" update the help pages to include information from the guidelines.
WAC: Testing software on users reveals how easy it really is to find features.
JG: But for users who don't know enough to know what to search for, what do you do?
KB: Potentially worse: having a separate accessibility page that is incomplete.
CO: Very hard to get people to change location of where options are configured. Easier to get cool keyboard access.
CO: We had same issue for Win95 accessibility dialog.
JR: Proposal: guideline to address the accessibility of installation programs or wizards? (Priority 2).
HB: Help systems must be accessible.
WAC: 7.3.1 Provide a description of accessibility features in the on-line documentation.
Should be Priority 1.IJ: What about in conjunction with 7.3.3?
CO: Why is 7.3.4 there? Does this mean that a browser has to provide a braille manual?
JB: Have learning disability people check guideline 7.3.
JR: Portability of documentation important.
WC: Note, some of our products may be useful for LD community, but are not designed for that community. Trying to bridge that gap may not help either the vendor or the LD community.
DC: I agree to a certain extent. However, there is a difference between a niche product and a mainstream user agent. They have different obligations.
JB: Disabilities overlap, so not always clear that a community is so different from another.
WC: We don't know the LD market, but if we knew what we could do to help, we certainly would.
IJ: Proposal:
HR: Define accessible electronic format (Plain text). Word documents can be accessible when there's a screen reader.
CO: Documentation is also available through fax-back services.
JB: This WG probably won't get to PR without another face-to-face meeting. Progress in these two days has been great.
WAC: Get all the WGs together for a concerted effort?
JB: This would probably blow timelines to smithereens. Chairs need to be coordinating more. Possibly a chairs face-to-face.
JG: Decision about face-to-face will be made at 4 December teleconf.
IJ: I think next techniques draft will still be hollow.
JB: Shouldn't go to PR with an empty techniques document. Need contributions of WG to fill this in.
JB: For those who haven't participated in phone meetings, is there anything we can do to encourage participation?
CO: On conference calls - lots of wish list stuff. Can we use conf call in a similar manner.
/* End of meeting */