Nearby: Agenda | Meeting information | Implementation report
Participants:
Regrets: David Poehlman, Eric Hansen, Nate Boone (MS)
Next meeting: 1 November.
Previous meeting: 11 October.
JG: To get out of Candidate Recommendation, we need to have 2 implementations of each feature. Ideas:
IJ: State of the world is: We are creating good deliverables, but if no motivation by companies to implement (e.g., due to state of the economy) then we won't get out of CR.
RS: Can we get the European Union to adopt UA.
WC: Do promotion among disability groups.
JG: How can the UAWG help you make decisions about implementing accessibility features.
IJ: What's the current status of impact of this document on your products?
SP: I don't believe that UAAG 1.0 is the major force behind our decisions. There are so many checkpoints, we look at it and wonder whether we will ever be able to achieve them. Section 508 is shorter (and yes, more broadly defined) and we would focus on that one before focusing on the 30-something checkpoints in UAAG that would be relevant.
JA: If you are not going to implement the DOM, it's too much to do just for accessibility. UAAG 1.0 is very useful to us at Opera:
SP: Does Opera have a team that is focused on accessibility? Or accessibility is just in the purview of a few developers?
JA: Both. Opera has grown a little, have two people involved in accessibility directly. We are looking for a framework (internal checklist).
LB: Usage is minimal. Section 508 is a "box" that is containing developers and organizations. UAAG 1.0 won't have impact until people get beyond 508. HP has its own guidelines. It's hard to build a business case outside of 508. When that's done, UAAG 1.0 will have a greater impact.
JB: My impression is that some companies are getting started with section 508. Some companies may only plan to do section 508, but I haven't heard that for sure.
JB: Should WAI develop a business case for UAAG 1.0?
IJ: Yes.
TL: My direct involvement with IE is less than what it was. However, UAAG 1.0 is one of a number of sources we use to drive feature sets. Other sources: DOM, CSS. Internally, we've already made the business case of what we should do. We are reluctant to say "We will do this or that," but what I have heard (without naming names) is that the P1 checkpoints are feasible (with several pieces of software in tandem). Internally, we need to make the business case that we need to do this. We've got executive buy-in, but we only have a certain number of developer-hours. The comments about 508 hold true for us as well: government sales are a big ticket. In short: the document is valuable, and we use it. It's one of several sources that implement feature sets, but the primary one will almost always be business (whether revenue, image, public relations, etc.). Microsoft is dedicated to accessibility, and for IE 7 (or whatever version it is), the development cycle is longer, so there is more likelihood that features can be integrated. This is a good opportunity to have this document looked at.
DA: For people like Opera and Home Page Reader (where there's a box on the shelf to purchase), it's easy to make the business case. But for free browsers you download, how do you make a business case?
TL: When Windows XP is shipped, a small percentage of cost is for each feature. There's a relative value for different features of a bundled application. The business case is: If IE is not accessible, we'll lose a sale of Windows XP.
JG: Part of what what influences your usage, then, is related to other development factors beyond your control.
RS: We use UAAG 1.0 to test what we have to do with Home Page Reader. We want to conform to the document. Section 508 has a bigger impact on the corporation, so we'll be focusing on that primarily. What we haven't done yet and need to do is create the business opportunity for people to implement the document. For instance, should some subset of UAAG 1.0 be integrated as part of Section 508?
/* General agreement and nods among developers that meeting section 508 is costing them quite a bit of money. */
RS: I think that UAAG 1.0 is more valuable since there is more technical information and experience behind it. One problem we have with UAAG 1.0 is that it's not done yet. We have a chicken and egg problem. We use UAAG 1.0 for other AT developments within IBM (other than HPR).
KHS: As a 508 coordinator, one good thing done in 508 was that the business case was tied to procurement. For each contract that's written, if you satisfy 8 checkpoints on the section 508 and another company satisfies 10, the other company gets the contract. When all companies satisfy 508, then the measurement will be displaced to UAAG 1.0; differentiation will be measured there.
TL: Also, as you check off 508 items, you will also be able to check off UAAG 1.0 items.
/* Refer tocomparison of 508 and UAAG 1.0. Jim Allan is also working on an update.*/
HB: Because UAAG 1.0 has so many more requirements, vendors will go after 508 first, and if they have energy left, they will work on UAAG 1.0.
JG: How many requirements in 508?
IJ: About 13 or so.
RS: Do section 508 requirements map to Priority 1 requirements?
IJ: The mapping is not 1-to-1.
JB: The authoring requirements in 508 include a section mapping to WCAG 1.0. But their requirements aren't specific to the Web. Same with the software requirements. It may help if we develop a comparability table for reference. To draw people more into our materials.
KHS: On procurement: If a product being purchased is software being used on the Web, you have to satisfy more requirements than just the software requirements.
JG: Jonny, does section 508 influence your design decisions?
JA: Section 508 has raised awareness of accessibility in the marketing department. So yes, it's interesting to us and we need to be aware of it. We feel relatively comfortable about the 508 requirements. It's more a question of where we want to go from here.
RS: Once we have a 508/UAAG 1.0 comparison, we can work with the govt. to have the extra requirements added to sectoin 508. This will help the business case for corporations. Until we do that, it will be hard to get buy-in. I think the 508 people have not considered everything that will be necessary to make the Web accessible. We need to work with them.
KHS: Yes, we need to work with the access board. They are interested in working with the W3C.
JB: I've talked to the access board a fair amount. One thing that I want to clarify: The next regulatory cycle for this is not even scheduled. It may not happen for several years. If your strategy assumes waiting several years (+18-36 months development cycle for software), this is a discouraging scenario. I've talked to the access board about other scenarios. For instance, references to UAAG 1.0 in their implementation Notes (supporting materials).
LB: My conversations with the access board: the information Notes are informative only; no teeth until the final rule changed.
JB: Yes, that is correct. There are more effective strategies we can pursue. You'll need a variety of strategies, and reference pointers won't hurt.
RS: KHS said that the access board realizes that there deficiencies in 508. Will it take the board several years to produce a new version if they acknowledge the deficiencies?
JB: Yes. With federal regulations, there are different frequencies for recycling this type of rule. 3-4 years or more to next beginning of revision process would not be unlikely. Then the development process itself may take several years (initiating the process to when the final rule becomes effective). There are other strategies to consider as well.
JG: Joint meeting with access board would be useful. Suppose we create a business case for UAAG 1.0, what would help developers in their implementation? Are there other materials than test suites, etc. that would be more valuable to developers?
TL: I don't think that the checkpoints are that difficult to implement. There are scenarios that are difficult (e.g., ActiveX controls, binary behaviors) - when you are relying on a third party. If you host something else, you introduce problems. The issue is getting the person driving development to push for the access features.
JG: So the test suites are handy, but in our case, we've got 18,000 test cases that we run already.
TL: Smaller companies will appreciate test suites much more.
RS: We might want to look at the European guidelines if not section 508. It struck us a couple of weeks ago when we heard that the EU was to reference WCAG 1.0.
JB: There is some work going on in this area.
JG: Jonny, what other materials would benefit you?
JA: The Techniques are useful. A test suite would also be useful. We don't have any accessibility test suite currently. Based on the way we work, it would be useful (i.e., since driven by developers, who like test suites; it will speed up implementation).
/* Jonny leaves */
/* Break 10:40 - 11:00 */
Review of draft UAAG implementation promotion ideas.
DA: Re: media visibility: Articles in the disability-related press would focus on products that meet access needs. But also articles in mainstream press about benefits and what is already done - highlight ease of implementability; most 508 articles are about cost of implementation.
JB: I've done interviews and quote the implementation report.
JB: I would appreciate if UAWG would look at WCAG business case.
/* We are having video feed problems */
KHS: The access board has developed a checklist for procurement officers. There is also a list of vendors that claim to satisfy 508. There's a template available at
JB: ALA developed a checklist for librarians (for ATAG).
DA: I was interviewed earlier this year by a business journal and would have appreciated speaking points related to cost.
JB: The idea here is to (1) have a reference business case document and (2) have an online slide show for presentations; talking points to drop into a presentation.
/* On plug-ins */
JB: Provide access to a bunch of plug-ins from a coherent place ("plug-in scattering").
JG: Is RealPlayer extensible through plug-ins.
SP: Yes. We publish SDKs that allow other companies to build on top of the system. If the companies who build plug-ins register with us, we can distribute through a central source. Is the goal development or distribution of plug-ins?
DA: Trace or W3C can provide a page that links to plug-ins.
JB: Yes, but if I were trying to use IE, I wouldn't look at the W3C site. I'd go to the Microsoft site.
/* Jon Ferraiolo (Adobe) joins the call */
JF: Acrobat has a plug-in architecture. Some plug-ins only work with the full product. The SVG viewer does not have real plug-in capability right now.
/* Networking among advocates */
JB: People are aware of the work we're doing. But some people don't feel confident about talking about the guidelines or talking about the amount of support in different user agents.
JB: Need to add to this section networking with AT developers. Also refer to Assistive Tech. Industry Association (ATIA).
IJ: What's the next opportunity to advocate?
JG: I'm giving a presentation at the ATIA conference in Orlando (20 January 2002).
DA: The next opportunity is tomorrow for me. <smile>
IJ: Can JG work with WAI EO to produce some slides?
JB: The challenging thing to write up would be the business case. Once that's done, creating slides would be a snap.
IJ: Can we get EO resources to do this?
JB: If the UAWG thinks it can come up with a comparable number of arguments, then I would say we could work out in a few joint meetings. I would recommend a group effort for this.
IJ: We might be able to work on this tomorrow.
/* Relations with others stds bodies */
/* Visits to individual companies */
IJ: I met with JF last week. We have mutual understanding on the requirements, but getting them implemented is hard these days.
JF: Currently UAAG 1.0 is not required; the executives are looking at the bottom line - there are plenty of benefits, but access features may get a lower priority than we'd like.
DA: Are test suites currently targeted at developers? What about procurement officers? What about repurposing the test suite for marketing?
JB: I like that idea for inclusion in the business case.
JG: Do developers find that, even in 508 implementation, it would be useful to interact with the UAWG to get implementation ideas?
SP: Possibly, yet. Part of the reason our SMIL implementation is complete is that we were heavily involved with that WG. Direct feedback loop is useful.
JG: Should the WG facilitate people's understanding of 508?
IJ: I don't want to start commenting on section 508.
TL: According to our legal department, we can't discuss it. I find the Techniques document very useful.
JB: It's a tightrope act:
SP: Include additional pointers to further technical discussion, even if about UA.
JB: In EO, we've talked about a rolling FAQ.
SP: FAQ is useful. More static or dynamic information is useful. Having someone available to answer questions would also be useful.
JB: That could be a person or an alias.
JF: I think that there has been a good educational exchange between WAI and UA.
IJ: How is Adobe using UAAG 1.0 today?
JF: Acrobat 5 was being developed during an earlier last call, and Adobe was paying attention. We considered some of the UAAG ideas for Acrobat 5. The SVG Team hasn't put much effort into access suppose in the SVG viewer. We are reviewing UAAG 1.0 in careful technical detail for future implementations. I don't have any new questions (since Ian and I have been over a lot of issues).
IJ: What can you share with developers?
JF: The hardest part of UAAG 1.0 for SVG is the time-based requirements. Some of them will prove difficult for us to implement - e.g., figuring out where an interaction will occur. You can get some information through markup, but it's too much effort for us in this area in the near term.
JF: Other requirements related to switching between alternative views of conditional content.
IJ: We talked about rendering in other views. A couple of issues:
JF: It doesn't seem like making this content will win us much from an accessibility benefit.
IJ: That seems to contradict WCAG expectations.
JF: But the <switch> statement in SVG is used for a bunch of other stuff.
IJ: This is counter-intuitive to WAI PF expectations: design more general features that may be used for accessibility features.
JF: We have limited resources. If we have to choose between MSAA support and extended <switch>, we will likely do MSAA; that will give users access to <desc> and <title> elements. It's unclear whether the higher cost <switch> element will be useful since it's used for so many other applications.
JF: Consider turning scripts on and off. You want scripts some time to make content more accessible. Same with switch statement: by allowing users to choose from alternate versions, you may make useful information inaccessible.
IJ: But that's up to the user to decide.
IJ: What about <switch> in SMIL?
SP: I understand JF's point: because it's used in so many ways, and because content authors may not be aware of all of the uses, gets complex for developers very quickly.
SP: For SMIL, <switch> has some great benefits, but you are dependent on having competent authors. It's difficult to create a product where you don't let authors create unusable content.
TL: Yes, I agree that's an issue.
JG: Do you have an example where someone might use <switch> to pomote accessibility?
/* JB leaves some time in here */
/* Refer to "Accessibility Features of SVG" */
IJ: One might use switch to choose between animation and non-animation.
JF: But how many people will construct this type of document? SVG spec renders as though the spec had no <animate> element. Anyone who cares about printing will have already done the right thing.
IJ: Our spec is not element-specific; I don't know what to do when an element or attribute is never used for accessibiliity purposes.
TL: Is this really a problem? Specs are all fine and good. Then you get content authors involved... How people author content is beyond our control.
DA: Are there hundreds of ways to implement <switch> and those are not interoperable?
JF: It's definitely possible to write SVG in different ways to get the same visual result. The <switch> element hasn't changed much from SMIL.
/* Lunch 12:30 - 13:10 */
/* Kathy Demaree, Microsoft joins the call. Program Manager for
Windows Media Player.
Stephanie Potter from RealNetworks here as well. */
/* JG gives background of W3C Process to explain how we can get out of CR */
KD: I own accessibility for WMP. We focus on:
KHS: Companies won't make 100 versions of a product. The US govt. is the largest purchaser of software in the world. Companies start with that, then add features to satisfy requirements for other countries.
IJ: Are you getting demand for accessible multimedia players?
KD, SP: No.
SP: We do get email from individuals.
TL: Could mean a couple of things: you're doing a great job already or there's not a significant market demand yet.
IJ: Or that there isn't accessible content available on the Web.
KD: CD playback is a big usage scenario for our product. Less so for mixed multimedia.
KD: Also a question of the ease of creating these things.
WC: Even Magpie?
JG: Yes, even with Magpie, requires some effort (notably for content not supported by WMP).
/'* Kip Harris (IBM) joins the call in Austin */
KD: Most multimedia content comes from small producers.
JG: The Quicktime player doesn't have a captions switch. For captions, we've talked about rendering them in a separate window. We have no implementation experience for repositioning captions.
KD: Adding captioning positioning increases a test pass exponentially.
SP: What about layering and overlap?
KD: You can embed the WMP control in a Web page and place the captions anywhere on the Web page. The user can move the text captions on the Web page (with scripted interface). This would be for SAMI.
KD: We do synchronization and make captions available, but we don't do positioning. The technical issue is not a problem, it's just not high priority.
SP: We don't implement the DOM; why should we implement it?
TL: Suppose that someone in the WMP project says "We have to ship on this day. Here's my list of features. We have to cut one. I can cut mp3 support or I can cut separate viewports." That's often what drives the final feature list.
TL: If you add a viewport, you have to consider lots of different scenarios (e.g., does viewport close when WMP is closed?).
WC: In looking at rationale for 4.6, the arguments are "may". You need to sell the need more clearly.
KD: Our captions area is resizable. Captions are never on top of the windows. There's a big performance issue rendering a trident window on top of multimedia. Microsoft's chosen captions implementation (SAMI) is rendered by trident. It can be done, but it's a bad user experience.
SP: We have similar issues - we can overlay windows, but author may have used bad colors or no transparencies.
/* Discussion about whether user or author should have final say... */
IJ: Why does final user control cost anything to the author? If a choice between not working at all for the user and working somewhat (even if breaking some presentation), what's the cost?
WC: There are a lot of issues. Many users are not savvy enough to configure their UAs. If UAs break, users blame the author, not the user agent. Money and revenue are important to content providers.
IJ: Our entire document and philosophy is based on final user control. If we ignore that, we can throw out the document.
TL: It's not black and white. The cost to the author - they don't want certain aspects of presentation modified. Law or diminishing returns. It comes around to time and resources.
KD: The user cannot be king in all situations.
JG: We have lots of implementation experience for changing text colors.
KD: Yes, these are things that can be accomplished.
SP: I don't think that we have to throw out the assumption that the user has to have the final say. But the assumption is rooted in the ideal world.
KD: You don't have to throw out UAAG 1.0. It is our general feeling that the user should have final say. Sometimes there are business or technical reasons why the user cannot.
TL: So if no one is going to implement a checkpoint, does that mean that the checkpoint should be deleted.
IJ: This may lead to the document being held hostage...
RS: I think that you all know that that's what you are doing. That is a consequence of non-implementation.
JG: There is substantial user control over text representation. What other areas would the author accept / not want control.
TL: You have HTML stuff and you've got streaming media. The two are not comparable from technology and marketing. It's important to content providers that the user experience be a certain way (for multimedia). For Web sites, they want as many visitors as they can get.
RS: We've been looking at this question a lot at IBM. If a user cannot use a piece of content, it's irrelevant if the information is presented a particular way. The industry has not addressed this issue, and it must.
TL: A streaming media content provider is a whole different breed of cat than a Web content provider. When media providers understand that they can increase audience, things may change. Marketing people are ruthless in getting their message across in a particular way.
JG: I understand that content providers are very concerned about being able to propagate what are essentially formatting objects. Part of the power of the Web is that content is available in many different ways. Authors aren't aware of this. I have a hard time promoting accessibility at the University; authors don't really care.
IJ: If you think that these features will be useful to authors, and authors don't get it yet, why not do it?
TL: Because authors don't want this yet.
KD: content providers - we need to fulfill their goals. therefore we jump for them, otherwise nothing for them to do. Moving captions around: if we worry about that issue, we technically could do it, authors may or may not be happy.
JG We don't say "don't change logo color."
KD: for 508 we only comply w/high contrast. our product does not allow to change colors. We have a certain way our product should look. One 508 is that it should respect color/font sizes.
JG But you can change it w/skins.
SP: - We used to do it, but now only do skins (to control the applicatoin UA, not the content).
JG So you can control colors.
KD:: How i don't control content: if we provide a border, and in a skin that doesn't have a skin that supports, will take out of skin and put in full mode player.
RS: What's preventing an intermediary from modifying content on the way to the user (on the fly transformation)?
KD: You may be breaking a license agreement.
SP: We might have an end user license agreement that content has to be displayed in a particular way.
JG: Could content provider detect that high-contrast settings are in place?
KD/SP/TL: No.
KD: SAMI captions are rendered with Trident.
TL: You can control this through Trident.
KD: We have an author-controlled way
IJ: Standard color selection mechanism of the OS seems like it would be the cheapest way to do this...
RS: I think everyone can find a business reason not to do something. I'm trying to understand what the technical reasons are behind why these requirements can't be implemented.
KD: Some features are techincal difficult, others undesirable:
/* KD, LB leave */
/* Break 14:38 - 15:10 */
JA: RealText renderer is basically rendering HTML.
SP: We don't let you modify the renderer programmatically.
WC: To sum up:
SP: Now that 508 has happened, the answer is yes. The law will be obeyed since purchasing decisions will be based on it.
JG: Same for wheelchair ramps.
IJ: How do you implement "longdesc" in HTML?
KH: We added nodes to the DOM (anchor and all). It took 10-20 lines of code.
KH: We've done a few things with articulating table headers. I don't remember implementing "abbr".
JG: What about scope/header/TH, etc.?
KH: We did implement them. I think the algorithms aren't that sophisticated. We don't implement rowspan and colspan.
IJ: Have you played with techniques for rendering content in separate viewports?
RS: We render links in another viewport. We also have a text view in a separate viewport.
KH: The text view is not a source view.
KH: We decorate headings. We announce the beginning and end of forms. HPR adds value through heuristics for finding labels for controls.
JA: HPR does implement "abbr". One thing for visited links - e.g., "Been there" can appear on visited links, and you can search for "Been There" on your page. Help you remember a path that you once followed.
KH: We do find the DOM useful generally as a cache. I think I saw some references to this in the Techniques. E.g., in a numbered list, we find it useful to compute numbers and stuff that back into the DOM.
TL: IE doesn't support NOFRAMES content. You can get at it through a piece of software. Our parser may strip out NOFRAMES (before it gets to "I-markup services"). So it wouldn't be available through MSAA (to the best of my knowledge).
/* TL does a test: View Source shows you NOFRAMES content when you have selected the whole frameset, not a particular frame. */
TL: Lots of authoring tools generate a NOFRAMES message: "Your browser doesn't support frames."
IJ: Do people find that people are using the HTML accessibility features?
RS: No, I think that most people are not using them. For example, it's still like pulling teeth to get people supply alt text. Getting people to provide table markup is almost impossible.
/* Rob Relyea joins meeting */
HB: What about table captions (the CAPTION element)?
RS: Not a lot.
/* RR talks about some accessibility features of IE */
INPUT type="file" now works with MSAAJG: Not clear that Jaws uses the IE DOM. They create their own. Their major complaint was speed; they are out of process and DOM access lags behind user interaction. How do you make decisions about DOM v. MSAA?
RR: In IE 6, we rounded out our support for DOM Level 1. For programmability, we will continue to enhance access to objects. MSAA is driven by requests from screen readers. IBM HPR makes requests for DOM access. Some AT developers would rather prefer to write to a system level API, not one specific to the Web. These AT developers would turn to the DOM if the MSAA path isn't working.
JG: Freedom Scientific has more Web-specific features than some other AT developers.
JG: What about access to conditional content (e.g., alt, title, etc.)?
RR: We don't throw the property out, but we don't support it. Note that for MSAA, we expose certain information based on our own calculations; if the AT wants other information, it will have to walk through the object model itself.
JG: What about keyboard support?
JG: Not everyone needs an assistive technology. Do you think about built-in support for features like longdesc?
JG: What about NOSCRIPT and NOFRAMES? Our document requires that there be a switch.
RR: We have a switch for NOSCRIPT but not for NOFRAMES. You can get at this through view source.
RR: There was a bad problem in IE 6 - distinguishing something scrolled off the screeen from something on the screen but invisible. We made improvements to the 'visibility' property in MSAA, but added an 'onscreen' property. There are four states. You can be on/off screen and hidden/visible.
/* 16:20 - HB, RS, KH, JA leave */
IJ: We are looking for things to tell developers that there are straightforward techniques for solving some of these issues natively, without breaking the UI, e.g., by rendering in separate viewports. Any ideas?
RR: You can write plug-ins to walk the DOM and find longdesc, provide access to it, etc.
JG: Yes, you could walk the document for event handlers, allow navigation of a list, and allow activation. I've had students do this. And other AT developers. What's the strategy within MS to get these things implemented?
WC: tabindex and accesskey are broken. Behavior varies widely across browsers. Depending on which element you've put tabindex on, your order can be messed up. We have problems with at least IE 5.
TL: I use tabindex. I set tabindex to "0" for a lot of different things.
WC: In both 508 and in WCAG 1.0: if you have a navbar, people will want to tab past the list of links. So, for example, tabindex=1 for the navbar.
RR: There's not container model for tabs.
WC: The MAP element is used to group links (HTML 4.01). MAP should have an effect on the tab order. I agree that the spec is one of the reasons that tabindex is broken.
RR: I'm interested in finding out a prioritized list of issues. And I know you've created a prioritized list of issues. What features do users want most?
SP: If you don't prioritize within the 36 P1 requirements, how are we supposed to decide what to do?
JG: Does it help you to understand our opinion of where you already stand?
SP: We may already know.
/* Problems about choosing and picking requirements based on disability */
IJ: With IE, we've been trying to get keyboard-driven selection for ages. Already implemented in the product, but not exposed.
RR: It's not entirely symmetric, you lose state.
TL: If we expose, product support needs to support i.
SP: Suppose a newbie user goes around flipping switches, and they change their caption foreground and background color to the same.
JG: You can provide a default settings button.
IJ: Or bury them in the user interface.
SP: Let me clarify: that users can screw up is not the sole reason we don't do some things; but it is a consideration.
JG: One of our requirements is to respect system settings.
/* More discussion on business case driving features */
SP: I think it would be more effective to address content authors first.
TL: There are things we don't do because the support cost is high.
IJ: Yes, that's inevitable when the user has increased control.
WC: When you learn to design an interface, you learn that before you allow the user to do something drastic, you ask them to confirm. Even when they confirm you have to allow them to back out of it.
RR: We have fewer resources for accessibility (of IE 7) than we had in the past.
IJ: How do we get in the MS door?
WC: Can MS sit down with the appropriate managers who develop proposals and work with them? Do you have to show cost/testing/user scenarios?
RR: Every release there is a limited window.
IJ: What is our channel for access? Customers have access, what are our channels?
RR: Talk to Tim and myself about the top features. We will balance bang for the buck and what's possible in the next release. The more we hear about it from different audiences, the better.
JG: Prioritization path may be:
SP: We need to set expectations that this will not happen overnight.
WC: You should show development cycles to the Director.
IJ: Director still wants 2 implementations.
RR: Accessibility should always be a piece of the pie, even if it's a small slice.
JG: If our process requires more time but improves accessibility, I'm all for staying within the process.
TL: Tight participation (from W3C) in the development process is unlikely.
WC: Do you think that other W3C groups are getting more implementation experience since Member-confidential? (e.g., SVG).
TL: Here's you influence IE.next: if you come to me and say "If you implemented these 8 things...."; We would take that input and go reflect on it.
/* Adjourned 17:15 */
/* 9:00 */
Participants:
JG: Objectives:
WC: What ER and WCAG have been doing:
IJ: General question - UAAG 1.0 has some vague requirements. We've tried to minimize them, but there are some external references. How do you handle these?
WC: One thing to do is to tell people what questions to ask. The WCAG audience is diverse non-technical and technical.. Tests are more detailed at the developer level.
JG: What do we need in our test suites?
WC: What about other test suite frameworks: DOM, XSLT, SVG? WCAG's framework is not detailed at all.
IJ: What are the biggest pieces we need to look for?
LH:
LH: For both work at OASIS on XSLT conformance (refer to Oasis XSLT/XPath Conformance TC work page) and DOM WG, there is an assumption that much will be submitted. If you're ont expecting much in the way of submissions, considerSVG model.
JG: I think our top coordination issue will be WAI WGs.
WC: We expect contributions from the outside.
IJ: I expect contributions from other W3C WGs (e.g., SVG WG for SVG 2), WAI WGs, and UA developers.
WC: We will have content developer contributions; need to give them a framework. We need to coordinate with QA.
JG: I spent a lot of time reformatting evaluations.
WC: We have an application that generates EARL automatically. Can use XSLT to create a report out of various EARL files. We are creating a Web form.
LH: Several places in the pipeline:
IJ: We won't have to worry about byte-by-byte comparison of reference to result.
IJ simplifying:
TL: There are two big things going on to separate:
JG: I think there are two things that the WG has to deal with:
TL: Carrying the UA testing framework forward: it's certainly feasible to write test cases for every checkpoint. The problem is going to be the open-ended ones (how do you know that all messages in the UI have a text equivalent?). It will be hard to represent behavior (might need a meta language)....
IJ: What techniques from industrial testing can we / should we incorporate into our test suite process? What can we do to enable UA testers to do what they want to do in testing? What kind of door can we provide?
TL: Scenarios. If I could go to the IE test people and say "here are N requirements and for each one, here's a user scenario." The source looks like this and the user should see something like that.
/* IJ wonders what regression testing would be interesting or relevant to UA test suites. */
IJ: LH, what is already being done in different test frameworks to document scenarios?
LH: Not done in XSLT. I may be using the term "scenario" in a different sense. In the language used to described an XSLT test case, they encode information about special environment or procedural considerations that enter into running that test case.
TL: When I use the term "scenario", it usually means "user scenario".
TL: We like small tests (no more than a half a page of HTML, for example, that only describes one situation).
WC: ERT test files are very short.
LH: Represent verdict criteria in prose, document allowed deviations. Some scenario per TL description is part of SVG test case description.
LH: Also, related tests, navigation links (this is test suite topology).
TL: Our test cases are typically stand-alone pieces (in part due to fact that we are developing under the gun). The test harness holds all of the tests (thousands of them). Test machines will subscribe to the machine hosting the tests. It takes 100 machines 18 hours to test a piece of software, for example.
TL: "Teacher / pupil" is one model. This is the most successful model of testing - keep tests independent, hand them to available machines one after the other.
TL: In the UA case, you've got fewer test cases and an unlimited number of UAs.
JG: What I've heard:
JG: But we have to add value.
/* TL comments on yesterday's meeting that some negative feedback does not mean that people aren't listening: people are paying attention. */
TL: On open-ended questions - you can't test for negatives.
IJ: Are we using the term "catalog" to be an umbrella for a list of test files?
LH: Not exactly: I use "catalog" in the XSLT context to mean either
TL: Where I work you have:
LH: I reserve "test case" for the most atomic information.
IJ: Summarizing:
TL: Don't get bogged down in an overcomplicated solution. If you can get EARL and LH's work to co-habitate in a multi-UA environment, that would be grand. It would be extremely cool. It would allow us to compare IE 5.5 to Netscape X, we could be reasonably certain that same tests were being used.
TL's top things to give testers (and this would be a big win; test managers read bug reports):
IJ: What about providing examples that will speak to developers (e.g., "Try this, or don't just limit to this").
TL: I think that suggestions will become apparent if necessary. Don't push techniques on to authors.
JG: Two stage process:
IJ: I don't think we should look at MSAA testing. Out of scope.
Next steps:
/* LH leaves */
/* Break 10:40 - 10:50*/
/* Randy Marsden (Madentec), Mark Nelson and Jos Eckhart (AI-squared), Glen Gordon (Freedom Scientific), Aaron Smith (GW-micro) join */
/* JG summarizes where the UAWG is, seeking implementation experience */
AS: We stick with MSAA. Haven't done much with the DOM. We haven't ruled it out. Our goal is getting our XP version out the door.
TL: MSAA gives access to the DOM; check out MSDN.
JE: We are mostly working with MSAA, but due to some of its limitations, will also try to get information from DOM.
JG: What issues have come up with alternative inputs (and MS IE, for example)?
RM: We are less dependent on open interfaces. We are less dependent on MSAA, even. (Issues of MSAA port on Japanese version of Windows). I think that for non-screen reader vendors, MSAA less critical. We have DOM plans, but that's for the future.
GG: We use MSAA somewhat.
/* IJ summarizes UAAG 1.0 API requirements */
RM: Publicly documented APIs don't always work; things break when OS changes. We rely on trial and error. I know AT vendors should be more involved in this process. But the reality is that many AT vendors haven't heard of the work the UAWG is doing; they are trying to keep their companies going. An awareness compaign would be useful.
RM: Perhaps ATIA should have a representative on the UAWG. I think we need a spokesperson familiar with the technical issues. There's an interoperability subcomittee in the accessibility forum.
JG: What has the impact been since 508?
GG: People are reacting - "help us make our product conform to 508".
RM: I don't think many AT developers were involved in the creation of 508.
MN: Companies who approached us wanted their Web sites to be accessible. One OS developer also approached.
RM: I think the effect of 508 will be felt longer term. Section 508 has opened the door to awareness of accessibility.
IJ: Do you talk about UAAG 1.0 to vendors? Would you make requests with respect to UAAG 1.0 to create demand? Or is the resource issue critical?
AS: We don't get into details about what a vendor's product needs to do.
MN: Same here.
RM: I think there may be a chicken and egg problem: No real advantage to MSAA unless supported by mainstream vendors. The demand is placed on AT vendors appears when critical mass implements a spec. But vendors may only implement when they think there is an AT vendor demand.
RS: HPR abandoned Netscape for IE some time ago since IE supports the DOM and other accessibility features outlined in UAAG 1.0. In terms of creating an accessibility solution, I'd rather see vendors supporting UAAG 1.0; 508 is inadequate for Web access.
GG: I would second RS's comments. There aren't that many browsers on the Windows platform that the world cares much about. There aren't many browser developers coming to us and asking "how do we make ourselves more accessible." There aren't too many people to whom we can advocate.
IJ: Can you say to IE "We want UAAG 1.0?" Can AT developers provide a business case (that would help our WG)?
GG: We don't have the luxury to look far into the future. We are mostly dealing with immediate needs.
TL: Right now, IE 6 is already done. No one is working on it. We're onto IE.next. But IE 6 won't be available to the public until 25 October. The AT vendors are always in the game of catch-up. The user base is a generation or two behind. Microsoft is always moving ahead. Hard to get resources to help AT vendors catch up. AT vendors may be "stretched out" over a three-year peroid.
RM: Yes, that is an accurate description.
RM: Right now, claims of conformance to Section 508 are not verified. Perhaps we should rank "degree of compatibility" between user agents and AT technology.
/* Jim Allan joins by videoconference */
RS: You have to have an AT solution to be useful. There has to also be a business case for the AT vendors to work with UAAG 1.0.
JG: Something that came up in our discussions of testing this morning had to do with using MSAA in a consistent manner. Do you see any need to coordinate the way MSAA is implemented? Or is this not a big issue?
AS: We're not too concerned about this. When a company comes to us and wants to work on MSAA, we work with them. We talk about other software as well. We just want the software to be accessible.
GG: MSAA implementation varies from app to app. Consequently we need to special case our software for different apps. We write special case code even if everyone is using MSAA.
JE: Our experience is that even if everyone uses MSAA, we still have to special-case the application - people use MSAA in different ways.
JG: What about other operating systems besides Windows? What types of issues come up with accessibility APIs in these other environments?
RM: We no longer support MacOS because of resource drain for fixes every time the OS changes. In particular because there was nothing like MSAA.
/* IJ notes checkpoint 12.4: "Document changes from the previous version of the user agent to accessibility features, including accessibility features of the user interface. " */
RM: From an economic standpoint, I'm convinced this was the right decision, even though some people screamed.
KHS: Are you familiar with Alva Access (which uses the Java environment)?
JG: Alva discontinued their screen-reader product.
KHS: They started developing again.
IJ: Referring to 12.4: If Apple had documented changes, would that have helped you?
RM: Absolutely. No documentation meant that we would only be able to react to unexpected crashes.
/* IJ thinks that 12.4 needs to mention value to ATs of documenting changes. This is good rationale */
JG: What about Unix? Somebody mentioned Gnome. Have any AT developers been working with developers in this environment?
GG: You go where the market tends to be. There's not a great business case for a market in the Unix world.
RS: I was involved early in some of the specifications for the Gnome API. There is a problem finding AT solutions for Linux or Solaris.
JG: What about Java?
RS: We have been working with Java at IBM.
GG: There continues to be interest in Java (it's being pushed by the corporate sphere). But the push is not coming from all quarters.
RS: Java is primarily a corporate intranet solution. E.g., java applets may be too big for a modem, but ok on an intranet.
RS: We have a cross-platform (Java) screen reader. One of the tricky things is response to color and font changes in the operating system.
AS: We don't have experience with the Java environment. We have serious plans to look into it, however.
RS: In the last year, use of java applets on intranets has gotten very big.
IJ: AT developers interested in tracking test suites and evaluations of user agents? Does that sound interesting? Do you have experience with? Any interest in participating in their development?
JG: Related - would AT developers like to make claims to conform to UAAG 1.0?
GG: Yes, it's great to have a test suite to see that we are doing the right thing, and to show other people as well. I'm a little concerned with what "meeting a requirement" means. Will we forced to represent something in a way we don't consider optimal. What about subjective results?
IJ: Our test results would never be so specific as "You must say 'button' before a button is available."
GG: Another side benefit - create a video to walk the uninitiated thorugh the test suite and how a couple of tools might respond.
IJ: We are also working on a "How to evaluate" document...
JG: We will also have links to other implementations.
RM: As an internal tool, a test suite is very useful. As a tool for the public, it's more dangerous.
JE: It would be helpful for us for testing our own products.
AS: Yes, we are for it.
IJ: We welcome contributions of any test informtaion you may have already developed.
RM: My suggestion - give a session at the ATIA conference.
JG: We've tried in the past and people seem to be very busy; people have commented that it's not a good time.
RM: It may not be a great time, but it may be the best time.
/* Lunch 12:10 - 13:00 */
/* On the phone: HB, RS, Glen Gordon, Cathy Laws (IBM) */
HB: Text-to-speech is an opportunity to tailor to a user's hearing profile. There are way to adjust a text-to-speech engine to accommodate to a listener's hearing deficiencies. Style could be applied (e.g., to emphasize plosives) so that can be read in a particular way for a particular user. There is a guy at England who showed a CSUN demo on modifying how phonemes are pronounced.
JG: How are speech browsers planning to use our document (for conformance or other)? I'm pretty sure that HPR and Jaws implement our speech requirements already.
GG: What ends up driving us, more than adherance to standards, is a customer making a particular demand ("you don't do X"). Adhering to a standard may have been helpful earlier in our existence.
IJ: What about using the document as a resource?
GG: We use it as a resource, but largely after the fact. "This is blatantly missing, we'd better add it."
CL: Early in HPR development, we used UAAG 1.0 more. As GG send, we need to hear customer requests for features.
JG: How much configuration is available for fine details of the SAPI speech engine. I know you provide rate, volume, pitch, and voice family control.
GG: Although we do support SAPI, it's not our primary interface. Our primary interface is home-grown. We do have SAPI and eloquence drivers (largely for hardware synthesizers). We are providing the same functionality as SAPI to the user. We allow configuration of voice family, rate, pitch, and volume. We don't currently provide much for different voices to represent different attributes (in HTML). Also allow change to pitch range. When you say pitch range do you mean pitch baseline or voice effects?
JG: For checkpoint 4.15, there are a couple of ways to satisfy:
GG: You can change the speed, and change voice properties.
IJ: How is HPR using the UAAG 1.0? Any expectations about conformance?
CL: It's just one of our many sources of requirements.
RS: We do use it to gauge how well we conform currently. If our schedule permits, we add features.
/* IJ asks about VoiceXML 2.0, published by W3C today. */
IJ: Anyone working on voice input?
RS: At IBM today, voice input primarily being used by voice server.
GG: We know the buzzword. We haven't done anything with.
RS: One of the biggest problem we have w.r.t. speech - the DOM that you get from IE is not the same as the structure ultimately rendered.
GG: You took the words right out of my mouth.
IJ: Our document "starts with the DOM". Refer to definition of "repair content".
RS: IE currently does not reflect repair in the DOM. We think it should be done.
TL: We made a conscious decision not to include repair content in the DOM. Rationale: Assistive Technologies may wish to do their own repair. Primarily we are doing repair just for the purposes of rendering on the screen. We make some assumptions, but don't modify the underlying DOM.
RS: If it's possible to write to the DOM, why not provide access to the DOM after correction "as well."
TL: May have something to do with resources and performance.
RS: This is a problem for ATs.
GG: Two hard issues for us:
GG: What's being thown at us on the front lines is coming at a different speed than some of the issues that are being quantified more officially.
JG: This is primarily an authoring issue. How do you see the author's responsibility intersect with user agent repair?
GG: In terms of using absolute positioning, I assume that the battle of getting authors to do the right thing is a lost battle.
TL: Would it be valuable to have a tree of some kind that contains the parsed mark-up after repair for visual layout (essentially two DOMs)?
GG: Yes.
RS: Yes. Repair techniques may vary between brower and AT, so better to have a single DOM available to both tools.
JG: I'd like to have access to result of a transformation to HTML in a DOM. This can give clues about the semantics of an unknown XML format.
RS: "dot net" stores a lot in XML. How does this information make it to IE (e.g., in HTML form)?
TL: The AT vendor is most likely to see they would see if they had received a mixed stream of different xml and binary formats. The ASPX people have tried to make this stuff conform as much as possible to WCAG 1.0.
RS: If you've got a bunch of different formats and the AT has to produce a response for the user, what will you have as a document model?
Action TL: Find out what you get from the DOM and from MSAA when you get a dot net application with mixed server and client-side chunks in it.
JG: I think there are some issues around XML and user interaction with XML that need to be worked out (in terms of ATs). Having a DOM available when XML translated to HTML may be useful.
IJ: Maybe take this to the WAI PF.
Action WC: Find out from WCAG and PF what plans are up for XML rendering and user interaction.
/* GG leaves */
/* 14: 10 *
KHS: I'm interested in terms of the connection for "V2". Also glossary stuff.
IJ: What is "V2"?
KHS: API for ATs. Refer to NCITS standards development.
Things we need to do / should do:
JA: I hope to complete this by next Thursday (1 November)
KHS: I'm interested in the 508 / UAAG 1.0 mapping.
TL: We don't have to count on 508 - it may give user agent developers a competitive advantage if they can meet additional UA requirements. Marketing people with run with this.
RS: Also, address European access requirements.
WC: Our timeline for a test suite framework is March 2002 (CSUN).
IJ: We may need to advance on a framework in a shorter time frame. This does not mean that I don't want to coordinate, only that we need to advance asap.
HB: How are we moving forward for checkpoints for which we have no implementation?
IJ: No definitive answer to this yet.
HB: We may have to relax a bit on some of the checkpoints.
IJ: We should try some more, and then if we decide we cannot get implementation, go to the Director and ask for advice on moving forward.
RS: May need to move some to version 2 of UAAG.
/* Discussion of Team confidentiality option for Members to report implementation */
/* Adjourned 14:45 */