|
| UAGL WG |
Member Events |
| UAGL WG |
Member Events
The purpose of the discussion is to identify missing, incorrect or misleading information in the techniques document. We will review each section of the techniques documentto identify
Chair: Jon Gunderson (JG, UIUC)
Scribe: Ian Jacobs (IJ, W3C)
Kitch Barnicle (KB, Trace)
Hans Riesebos (HR, ALVA)
Harvey Bingham (HB)
Mark Novak (MN, Trace)
David Poehlman (DP)
Glen Gordon (GG, Henter-Joyce, Monday Only)
David Clark (DC, CAST)
Judy Brewer (JB, W3C)
Wilson Craig (WC, Henter Joyce)
Jim Thatcher (JT, IBM)
Rich Schwerdtfeger (RS, IBM)
Gregory Rosmaita (GR)
Charles McCathieNevile (CMN, W3C)
Dick Brown (DB, Microsoft)
Mickey Quenzer (MQ, Productivity Works)
Tim Lacy (TL, Microsoft)
Legend:
[1] http://www.w3.org/WAI/UA/1999/10/wai-ua-f2f-199910.html#agenda
Reference document:
http://www.w3.org/WAI/UA/WAI-USERAGENT-19991005
1. JG: Run pwWebSpeak through the guidelines
Status: Contacted Productivity Works to finish the review .
2. JG: Contact Lakespur Roca related to posting for review of keyboard
support
http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0015.html
Status: Done.
JB: Lake couldn't come to the meeting. However, could participate by phone. Has comments on the usability of the guidelines.
Action Ian: Follow up with Lake on usability questions.
3. JG: Contact MR about SMIL techniques
Status: not done
4. JG: Review RS comments on current working draft and update the issue list
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0063.html
Status: Done.
5. IJ: Contact Microsoft about participation at F2F meeting in Redmond
Status: Done.
6. IJ: Contact Marja about writing a proposal for what should be changed
related to checkpoint 2.1 issues
Status: Done.
7. IJ: Split Checkpoint 1.1 into support device indepdence and use standard
APIs. Clarify that not all APIs required. Results dependent on Rich proposal.
Status: Done.
8. IJ: Propose a checkpoint like the ones for form about table summary
information (checkpoint 9.9 and 9.10)
Status: Done
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0092.html
9. IJ: Change title of Guideline 7 to reflect more than just w3c
technologies accessibility:
Done: "Implement open specifications and their accessibility
features"
10. IJ: Add checkpoint 6.6 to guidelines 7
Status: Dropped.
11. GG: Review proposal for techniques for accessing content. Status: Dropped.
12. GR: Write a proposal to address issues about spawned windows.
Status: Pending.
13. DP: Run Jaws for Windows through the guidelines
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0095.html
14. MR: Working on SMIL techniques in addition to SMIL access note.
Status: Not done.
15. RS: Propose rewording of Checkpoint 1.1
Status: Not done.
IJ: I proposed something.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0092.html4
IJ: Refer to Rich's response:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0096.html
a) Last call.
i) Contact chairs of dependent WGs (e.g., DOM)
ii) External reviews.
JG: Some ideas: Peter Korn, Earl Johnson, T.V. Raman, Lake Rocca, Curtis Chong, Jim Fructerman, Joe Sullivan, Mike Paciello, Håkon Wium Lie, Real Networks.
JB: Plan to contact people 4 times to ensure they do the review: before, when it goes to last call, during last call, at the end of last call.
JG: Coordinate through the chair (cc JG, IJ, JB).
IJ: Please send names to the list.
Action JG: Talk to WC offline about contacts.
Action HR: Find information about European contacts.
b) Proposed Recommendation. Start organizing press release/testimonials.
c) Recommendation:
i) Includes Guidelines/Checklists/Impact Matrix
ii) Publish the Techniques Doc as a Note.
JB: I recommend that the Techniques Doc be as stable as possible during Proposed Rec: strength of it will support Guidelines. Recommend pointing more visibly to it [E].
IJ: We'll have no time to work on Techniques during review period.
iii) Documentation of minority opinions/issues of concern (e.g., conformance).
iv) Press release/Testimonials.
JB: Please coordinate Testimonials through the W3C Team (IJ, JB). We strive for diverse testimonials (large org/small org/i18n). Since Authoring Tool Guidelines will be going to PR also soon, need to consider distribution as well.
RS: Is there a template?
JB: Yes, I can make this available soon. I prefer to send to individuals rather than just linking from Web.
SCHEDULE:
a) Go to last call: Start 29 October / End 1 December
JB: This is risky since right before AC meeting.
b) Go to Proposed Rec: 15 December (latest)
c) Go to Rec. Approximately: end of January.
JG: I think it would be helpful to have a face-to-face to process last call comments.
GG: Who else is interested in this process? Will new people come out of the woodwork during last call?
CMN: Yes.
JB: The last call announcement does wake people up. It's a lot better to get the criticism during last call, not Proposed Rec.
WC: When you solicit input from people who haven't been involved to date, don't you risk derailing the process?
GR: We hope the document is strong enough to educate new readers. If it doesn't, we have a serious problem.
JB: I agree with Gregory. The document needs to be able to stand up to public scrutiny.
GR (to WC): If you are going to canvass ATIA people, show them how to find the minutes and the mailing list archives, the issues list, and the search engine.
DC: Need to get promotion/implementation commitments as well?
JB: UAGL WG should track who is committed to implementing all/part of UAGL. Note that not all commitments will be public.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#78
IJ: The SMIL WG said "You can't just turn off spawned windows since you won't have access to some content.
GR: Instead of on/off, allow the users to control window spawning. Cascade:
a) Minimal: Nothing
b) Notify.
c) Prompt the user to continue
d) Allow the user to configure the previous prompting options.
JT: How do you present the information if not in a spawned window?
GR: A system message is different than a new content window. System dialogs don't cause the same problems.
RS: Like tip of the day.
DC: Are we not differentiating windows of the same application from windows of different applications? Or are they one and the same?
MN: It depends on what you're opening. Use the same cascade as is used by systems in general (e.g., you're leaving secure site).
HB: We haven't articulated how user preferences in profiles would fit in.
GG: I think that announcements are too onerous.
DP:
a) First question is what kind of window are we talking about? I think this
functionality would be great, but not always necessary. Perhaps it belongs in
the techniques instead.
b) As for GG's comments, I think that everyone should have this control in
their browser. This is a usability issue.
CMN: I agree with GG that this may be too onerous. It may not be an optimal solution anyway. The problem we're trying to solve is trying to reduce disorientation when too many windows on the screen. Having a history that spans several window instances would solve the navigation problem.
HR: My concern is with profiles. I don't like the interactive solution (at least for some users).
IJ: I agree with Charles.
GR: The specifics of the mechanism belong in the techniques document.
DB: There is precedent in Windows for opening new windows or not within the same application (e.g., directory view).
DP: Internet Explorer provides option of opening pages in same or separate window.
MN: Just a note about about using history - may not work if new process started.
IJ: Refer to Al's counter-proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0272.html
RS: One of the problems I'm having is the definition of "spawned window".
GR: Another possibility is to reword the checkpoint: ask for user control of notification of spawned windows.
JG: Spawned window: a window created by the user agent process.
DC: User notification vs. User control. I agree with statement earlier that user control goes further into new functionality. I'd be in favor of taking out the control part and strengthening the notification part.
RS: One way to address this: When a created window has not been initiated by the user (e.g., create a new browser window, help window, etc.).
IJ: Relates to checkpoint 10.1 as well: "Provide information about content and viewport changes (to users and through programming interfaces)."
KB: Users really are initiating, e.g., by following a link. I don't know that following a link will get PDF or PS, or whether will open in a new frame.
GR: In the definition of user-initiated, need to cover event handlers and scripts from HTML 4.
DB: Should authors give hints?
IJ: WCAG says this, but this is expected to be a UA functionality.
HR: What does the user *expect* to happen? This may not be related directly to automated or configured behavior, but user experience.
JT: Sounds like spawned windows means UA-controlled windows.
Resolved: "spawned window" means windows created natively by the user agent process.
DC: What about other disabilities than users with blindness? Any spawned window of the same class needs to have the same functionality.
GR: If the UA generates a new instance of itself, it must retain the configuration.
GR: Note: you don't want to have to turn off scripting in order to keep windows from popping up.
DP: Turning off scripts is not enough. The browser is aware that it has to load a plug-in. We need to distinguish between plug-ins and other applications here.
JT: These are usability issues, not accessibility issues.
GG: The accessibility issue is the knowledge that the spawning is happening. The usability issue is control.
GR: I think that in addition, the user agent has to inherit the configuration of the parent viewport.
RS: Proposal:
a) Define "spawned content window": A viewport created by the UA
process that displays content."
b) Allow the user to control spawned windows initiated by the user agent.
NOTE: For example, in HTML, opening a document in a new target frame,
author-supplied scripts. In SMIL 1.0, show="new".
KB: What does "control" mean? What does "user-initiated" mean?
HR: There are two levels of spawned windows:
a) Author-specified
b) User agent-specified.
GR: When following a link, the user-initiated action is following a link. Not opening a window.
RS: Define "user-initiated/author-initiated/UA-initiated"
Proposed:
a) Define "spawned content window": A viewport created by the UA
process that displays content."
b) Allow the user to control the spawning of viewports other than those created
as the expected result of a user action.
> NOTE: For example, in HTML, opening a document in a new target frame, author-supplied scripts. In SMIL 1.0, show="new".
KB: I have a problem with the word "expected". Who decides what's expected?
DB: What does "control" mean? It implies more than notification.
RS: Push that to the techniques document.
CMN: What's the minimal requirement.
WC: I have a problem with the concept of "control". How about confirmation/denial of spawned windows.
CMN: Does the user have to be able to have new windows spawned?
HR: I think we're still in G4: Turn off features that may impede accessibility.
JG: Is the minimal requirement a prompt? Or do we want to allow turning on/off.
DB: If it's notification, this goes in the orientation guidelines.
RS: I think this is a usability in addition to accessibility. You want to be able to shut off the notifications.
DB: Note the difference between the feature and the prompt. Say explicitly that you want both:
a) Turn on/off feature
b) Be prompted for the feature.
GR: What we want: (a) notification and (b) some level of control. The form of control is for the techniques. In Windows, prompt with the option to turn off the prompt.
DB: Examine priorities: notification higher priority than control.
Resolved:
NOTE: For example, in HTML, opening a document in a new target frame, author-supplied scripts. In SMIL 1.0, show="new".
DB: Perhaps say "When possible..."
e) Add techniques (e.g., Al levels)
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0272.html
f) Combine this one with 5.17 (control viewport size/position, P2.) ----
IJ: Priority of rendering according to natural language markup.
JT: No UAs read the markup today.
GR: Base functionality: (1) what the UA has to do to make the document accessible and (2) what the UA has to communicate. For "lang" in HTML, this could cause a font to be used.
GG: If I as a dependent-UA don't have access to the markup, I'm prevented from doing the right thing because I don't have the information.
JT: But the current checkpoint says render, not expose.
IJ: It's meant to be about rendering. The exposing part is covered by another checkpoint (the DOM checkpoint).
GG: I side with Jim. This is not an accessibility issue.
GR: I don't agree.
DP: Thanks to CMN for reinforcing the discussion. We're not talking about flags, we're talking about rendering content.
JB: I think of this example: user able to understand multiple languages, document includes text in multiple languages. You do need dynamic swapping.
RS: Is this a general usability issue or an accessibility issue?
JB: I think it's accessible. If I am sighted, I know the difference between different font families. If I don't have access to the visual clues with my screen reader, then I can't parse mentally.
RS: But what if I don't have the fonts.
JT: How does a graphical user agent notify the user of language changes. You're proposing adding content, which I don't think is appropriate.
GR: Just because the issue is one of usability doesn't mean that it's not one of accessibility.
CMN: If you can't find a technique for a checkpoint, that means that the checkpoint may be poorly phrased. The technique that comes to mind for me is to insert content that indicates "Japanese" or "ja". Is what's required here notification of the language or identification of the characters. Visually, you indicate the characters.
DC: Is this a requirement for the UA or the assistive technology. Can you conflate this into ensuring that all inherent markup is communicated to any AT?
JB: In response to Jim's comment, if the markup is improperly used, what should the UA do?
JT: Another technique - a kind of tool tip that indicates a language change.
HB: Note that Unicode characters unmarked up may indicate language change.
IJ: I'd like to get back to the accessibility issue: what's the priority of this for providing access to content?
HR: I think it's important to know when the language changes, not just when rendering is not possible.
CMN: What's the P1 requirement? As a sighted user, you recognize the characters used. "BAHASA" is not an English word, but Malay. They use the same (Unicode?) characters.
IJ: I would prefer to address explicit markup only, not Unicode characters unmarked.
DP: I support P1 because it will be impossible for some people to access content if its not rendered properly.
Straw poll: P1 - 6
P2 - 6
IJ: I'm relying on WCAG, but I can't say P1 or P2 based on my knowledge.
RS: If you want to support the Guideline, what's the technique?
WC: Can we split: P1 to notify. P2 to render.
JG: Note that AT can get the information through a P1 checkpoint already.
JT: This is not a synthesizer information - this is a user agent issue.
JB: Users need information that content is not being rendered by the UA. Easy for sighted users, not as easy for users with other output.
JG: I propose that we leave this checkpoint as a P1 for now (since P1 in WCAG) and ask for input during last call.
JB: Sounds reasonable. I think this is an area that has not been discussed in depth in other WGs. In terms of accessibility to different languages, people have not spent as much effort on this. Let's ask I18N IG for input.
JT: Final word: recall that these checkpoints are for the general purpose UAs. Who does this help if you're not sighted?
Mickey Quenzer (MQ) Joined meeting
Resolved:
a) P1: Render according to language identification.
b) P3: For identified but unsupported languages, notify users of changes in
language (when configured to do so).
HR: Risk of conflicting open specifications.
JT: These are WAI Guidelines, why would we talk about other specifications?
DC: If we broaden the Guidelines unduly, we run counter to the WCAG (which says use W3C specifications).
JG: So we wouldn't include something like SAMI?
CMN: The checkpoint about using W3C specs sends a message. But a UA can render other specs, so the other checkpoint (7.1) should apply to them.
HB: Note that "supported" is undefined?
IJ: "implemented"?
Resolved: Checkpoints 7.1 and 7.2 ok as is.
Action Ian: Repropose Guideline text.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#87
IJ: Proposed "adjust" instead of "control".
Resolved: Define "control" as "choose preferred behavior from predefined options".
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#88
JT: If you can't select specific elements, do you have to satisfy the checkpoints where this is required?
IJ: I think this is right.
ISSUE: Do we need to require UAs to provide a structured selection mechanism?
/* Demo of Amaya's structured selection mechanism: hit Escape to navigate up in the tree and modify the selected content */
IJ:
JT: I don't think checkpoint 9.4 is for general purpose user agents.
IJ Proposes:
a) Delete checkpoints that refer to selecting specific elements (links, tables,
forms).
b) Add a checkpoint to require a selection of mainstream UAs (without
specifying structure or unstructured).
JT: You don't usually select with the keyboard in graphical browsers today since there's no carat.
MN: In DOM2, every element will be able to be focussed.
JG: Two issues - the UI issues and what the underlying technology allows you to do. Do we want to require UAs to allow (device-independent) structured selection?
JB: Note - where are we putting checkpoints that get dropped because they are for ATs?
JG: We don't have a repository for them.
JB: I think we need to preserve them somewhere.
JT: Propose a P3 checkpoint for useful information on those elements that can be selected.
RS: How would you render (as speech) status information?
DP: My screen magnifier does this very well in the status bar.
(List of checkpoints that require a user selection: 3.2, 6.2, 9.4, 9.5, 9.6, 9.9, 9.10, 9.11, plus proposed table checkpoint from Ian.)
MQ: In the future, there will be other devices doing "Internet stuff". If you're using a speech browser over the phone, these functionalities become more important.
RS: I think ATs should be providing these special functionalities. The only time it should be required is when no other means is available (e.g., when you're browsing over the phone).
JT: "Where am I" function in a small device may be difficult to activate when there are few keys available.
DB:
a) Browser must not block available of info
b) It would be nice if the UA did these things, but not a requirement.
c) Configurability in this case is nice.
DP: Has there been thought about a separate document describing requirements for what ATs should do with information that's made available to them?
JB: It would be a great shame if the expertise of this WG were to evaporate without a trace. If there's no commitment of the group to follow up on the AT half of the picture, I have more misgivings about removing the dependent UA-related checkpoints.
DP: Delete the checkpoints in question. Put them along with the impact matrix. Create a Note for ATs.
DC: Put the AT requirements somewhere else in the document.
RS: You shouldn't make the UA have to render the content. What you want to accomplish is to make it possible for a dependent UA to get at the info.
IJ: But where do you draw the line on functionality? This has been the project of the WG for 1 year and a half...
MN: I share a concern about dropping several checkpoints suddenly. Note that AT developers are in the business of providing solutions that mainstream browsers do not. I'd like to see us raise the bar for mainstream browsers. In mind, there is no dependent UA. I don't want to put the AT developers out of business, but I want mainstream browsers to accomplish the same task.
JB: I like the Note idea.
IJ: I propose we put the AT-related checkpoints in an appendix in the GL document.
JB: I like this idea.
DB: Re where to draw the line for what should be required of a mainstream UA? I don't think that's it's reasonable to ask a graphical UA to render all information available graphically through other output means. But they shouldn't block that information.
DP: In the near future, mainstream browsers will talk. Need to take that into account.
GR: I agree with Mark and Dave. We should aim for what's the base functionality of a user agent. What is the minimum required for getting information? For communicating to other programs? I don't perceive this as "raising the bar" but rather setting up the bar knocked down by mainstream UAs. All adaptive technology has been compensatory - functionality that was overlooked.
CMN: I agree with GR, but said with the W3C-approved lingo. We keep missing this point: there are ways that mainstream browsers already achieve the goal we're striving to achieve.
RS: The bar has been raised by the DOM2 - making the selected element information available in a platform-independent manner.
GG: I feel like this WG is preaching to the choir. The groups that really need to make the changes are not in these proceedings; the effort is theirs. Publishing this document as a Recommendation will not suddenly raise the bar. Therefore, I'd put the emphasis on communicating with other software.
JT: I Propose moving these checkpoints to P3. The most important checkpoints are P1 and P2.
IJ: Proposed
a) Move dependent-UA checkpoints to an informative appendix of the Guidelines.
b) Add checkpoint about requiring a selection (structured or unstructured).
c) People will review the next draft and decide whether the split is ok.
JB: What if you are an AT developer and you look into the appendix and see a smattering of information (i.e., not a complete listing).
GG: Even a bunch of points is useful. I suspect that AT developers would not be unhappy with a grab-bag if the points stand on their own.
GR: I propose that the impact matrix should be the basis of a map to requirements for specific requirements.
DP: I agree with GR.
DC: If we put information in the appendix, we might be able to add more content for other disabilities not currently in the guidelines.
JT: As for point (b), is a selection feasible?
IJ: Yes, Amaya does it, for example.
CMN: Netscape lets you in composer view.
DC: A hack: mouse keys.
JT: But I think that the "natively" requirements throws that out.
GR: I would like to see Ian's proposal put into the next draft. Then we ask developers to review the draft.
Resolved: Adopt Ian's proposal
Action Ian: Put into next draft.
DB: Need clarification of 9.5 that this applies when there is appropriate markup indicating the link requires a fee.
DP/JB: User agent is the last line of defense.
/* Tim Lacy of Microsoft joins the meeting */
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#91
4.12 Allow the user to choose between a frameset or its alternative supplied by the author.
Note. For example, in HTML, allow the user to choose between a frameset or a NOFRAMES alternative. The ability to control frames is important for users with screen readers and users with some cognitive impairments.
GR: What's the priority of the proposed text? I propose making this a priority 1.
IJ: I agree. Note that this proposal is a particular case of providing access to alternative context.
DC: Add "rendering" to the checkpoint text.
JT: NOFRAMES content may not provide an equivalent alternative.
GR: It's true that many NOFRAMES act as commercials to go get new browsers. But I think that's due to no good implementations of the element.
DC: I think this should be a priority 2 since the page is not unusable in frame mode. It's more difficult to use, but not totally unavailable.
CMN: Often the most effective way of making the content of a frameset available is making it available in another place. I don't think contradicts what we're saying.
DB: Why is this one more important than other similar checkpoints in the document? For example, does the rendering of images make it impossible to get at content. (4.1).
JT: I think we can delete 4.12 because of 3.1
GR: Don't replicate the whole document in a NOFRAMES, use the navigation page as an index to the main content, and put that in NOFRAMES.
TL: I think that's a good idea - you avoid content replication.
GR: 4.12 is about access to content but also navigation. 4.12 bridges two checkpoints (access to content and navigation).
CMN: I think the navigation point is important and needs to be covered separately. I agree with deleting 4.12 but ensuring that it's covered (since commonly done wrong today) clearly elsewhere (e.g., techniques).
Resolved:
a) Delete 4.12.
b) Mention frames in 3.1 Note on access to content
c) Put Ian's Note in 8.1 on frame navigation.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#92
IJ: Form orientation.
GG: Hotkey access is important.
IJ: Covered elsewhere (G1 and G2)
Resolved: Move this to "AT appendix" (for review).
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#93
IJ: New definition of applicable.
DB: Risk of discouraging UA developers (e.g., for style sheets) by saying "you can comply more easily by not implementing a language than by trying to implement part of it." For instance, if a UA tries to implement speech but doesn't do everything perfectly, should they be penalized?
KB: This is related to the issue of browsers that only comply to a few checkpoints and the others don't apply. We didn't resolve how to address that.
DP: We can't force browsers to implement features, however.
MQ: WebSpeak has a lot better compliance than other browsers in handing off processes. If we're talking about browsers needing to handle content in order to comply with W3C, this is important.
CMN: A UA could try to comply by handing off your HTML rendering to someone else.
IJ: Seems like a stretch to create a new technology just to avoid accessibility features.
DB: I think you have to consider the practical side of taking the guidelines to the developers.
MQ: A number of multimedia players think they will be able to comply as browsers. WinApp is just a player, but its accessibility stinks.
KB: I think that for purchasing, in addition to conformance information, vendors will need to provide supported feature information.
JB: I agree with Kitch. I think it's also real life to think that developers may go to lengths to avoid implementing accessibility features that seem onerous.
IJ: That sounds like the original proposal + a requirement to provide information about what features are supported. But vendors do this anyway when they advertise their products.
DB: Style sheets benefit accessibility. How to you reward people who attempt to implement them?
CMN: CSS is the applicable W3C technology for controlling style. But there's a higher level requirement elsewhere (independent of style sheets) to control text size.
IJ: If you support CSS, you satisfy a bunch of checkpoints immediately.
KB: I'm comfortable with Ian's proposal, but I think the conformance issue is still complicated. We need to educate purchasers so that people can purchase appropriate software to meet the needs of users.
WC: Once you conform, the rest is marketing. The purchasing decision is made on relative functions.
DP: I share KB's concern about marketing.
a) Can we use impact matrix for marketing?
b) Will we keep a database of conforming software?
JB: If this WG doesn't have consensus about a conformance statement, I don't think the document is ready to go to last call.
GR: Create a support matrix - show what you will satisfy by implementing a particular spec.
CMN: Create a checklist à la the Authoring Tool Techniques.
http://www.w3.org/WAI/AU/WAI-AUTOOLS-TECHS
JT: In some cases, we don't have much to say about a particular checkpoint.
/* IJ discusses two structures for techniques document: semantics-based and list-based */
DB: I think developers will prefer (short) lists.
GR: Amen to what Dick said. Also, the numbering system used in the techniques document should match up to the numbering system used in the guidelines document. Mixing the numbering systems is confusing.
CMN: One reason we don't have enough techniques is that we don't get proposals from the WG. In AU, checkpoint-by-checkpoint techniques list was conducive to coming up with techniques.
DC: I think it's inappropriate to compare WCAG Techniques with UA/AU Techniques.
IJ: I hear people arguing that the list-view is useful. Are people convinced that the thematic view is not useful?
TL: I want to reinforce that developer thrive on lists. I also support Ian's proposal above. I don't think that a development group will *not* implement a language based on how hard it is to make it accessible. By the time you get to a developer, broad decisions have already been made. In this context, charts and tables (in techniques document) are crucial.
TL: A common question from the program management house: what will this cost in test and implementation time? Management will ask developers "What will it take to implement 1.1?" "What will it cost to implement this feature?" Big thick documents scare off readers. Checklists would be an inappropriate tool for answering questions about implementation time. In that case, there will be need for more information.
HB: Checklist valuable for Q.A. people as well. To determine whether a checkpoint has been satisfied.
IJ: This sounds exactly like the Techniques document.
JT: Techniques are suggestions, but not final words.
DP: Checklists might even lead to standardization.
HR: Beware of deviating from accessibility conformance to general quality conformance.
GR: Use the AU Techniques style. But include a link to the narrative information (which is separate).
DP: I get lost in multi-dimensional spaces easily.
WC: I think the WG should not focus on techniques. Let the developers come up with the techniques. I think it's pretentious of this WG to propose techniques.
CMN: I agree. However, this WG must come up with at least one technique for each checkpoint. If you can't come up with a technique, that's problematic.
RS: I agree with CMN. We should focus on the guidelines. We can't list all the protocols and formats in a single table and show which checkpoints apply (there are too many). You won't cover all the techniques. So let's finish the techniques document quickly, and get it out. However, need to fill in what's missing to substantiate the guidelines.
IJ: So three issues:
a) Structure of techniques document. I propose to "flip" it based on WG input today. CMN: Make the checkpoint the bulk of the techniques document. Send them off to the appendix.
Action Tim: Get feedback from MS IE Team on usability of 5 October Techniques structure.
Compare to Authoring Tool Techniques at
http://www.w3.org/WAI/AU/WAI-AUTOOLS-TECHS/
Suggestion to WG:
People can propose "tables" for the Techniques that help developers
by, e.g., listing which checkpoints must be satisfied for a particular
language.
Resolved: Implement Ian's proposal on applicability.
/* Ian shows W3C Talks as an example of wanting to select from among available style sheets */
DB: Why distinguish author from user style sheets?
DB: Proposed: Allow the user to select from available style sheets.
Resolved: Add this checkpoint as a Priority 2.
/* Adjourned 5:38 */
[1] http://www.w3.org/WAI/UA/1999/10/wai-ua-f2f-199910.html#agenda
Reference document:
http://www.w3.org/WAI/UA/WAI-USERAGENT-19991005
To process last call.
Action Judy: Follow up on hosting possibilities.
Action JG: Ensure that this is discussed at next telecon.
Action IJ: Announce this meeting being organized on the UA page and list.
CMN: Current draft has a guideline and checkpoints. I think this is too much. Keyboard access gives you a lot of bang for your buck, but shouldn't be emphasized as the end-all since it's not always the best thing to do. Shouldn't have an entire Guideline. You need to be able to work out functions without having to move through them spatially.
JG: Mousekeys does not satisfy the checkpoint.
IJ: I think the spatial issue is distinct from the keyboard API issue. Users will find direct and contextual access to functionalities useful. This is distinct from mouse/keyboard activation but also spatial/memory.
/* Do we delete G2? */
IJ: I support deleting G2 but leaving in the checkpoints in a more abstract form (capturing the requirement but distinct from the input device).
JT: I cringe at this. The checkpoints are already abstract.
DB: We stress the keyboard a lot. I'd rather see G2 left in.
RS: Having written the Java guidelines, I observe that applications are mouse-centric. Still get comments today on the effective section on the keyboard interface. I think a section on the keyboard is critical so that developers do this correctly.
JB: The keyboard needs to be singled out and talked about, even if there's not a whole guideline.
Resolved: Ok to leave G2 as is for now.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#97p
JT: The wording of checkpoint 9.3 is not good. Don't we already have a 'navigate' by structural elements. Is this a technique for 8.6?
DC: Both apply to techniques.
CMN: In AUGL, you need to be able to navigate according to structure.
JT: Why is this not for dependent user agents? This is a functionality that is nice, but the author should do this. I can see keeping 9.3 as a priority 3. For HPR, the view is navigable.
DB: I think 9.3 should be P3 or moved to the appendix. It's an implementation of 8.6.
HR: I think 9.3 is for all user agents.
IJ: Which is more important - the view or the navigation?
(Navigation).
Proposed: Delete 9.3 in favor of 8.6.
Proposed: Create a checkpoint from Note after 9.3 but for navigation.
CMN: Actually, 8.7 does what I want.
DB: I think that the outline is one way to allow navigation by structure.
MN: Caution: 9.3 is about orientation, 8.6 is about navigation. Do you want to lose this?
DC: Viewing by structure is extremely different than navigating by structure. The view is important to give users a sense of the document.
GR: Personally, I don't need an outline view. But it is probably valuable to be presented with the structured view and not have to create it as you go.
DP: If you're navigating by structure, you don't know where you're going to go. As a person with low vision, I want to know where I am in a document (as I navigate). I think we should keep 9.3 (P3?).
DC: Don't assume a purely serial perspective on the content.
JT: Navigation and view are the same in the serial case. Different in other cases.
DP: I may want to know more about the document without moving the focus. It's important for low vision and cognitive.
MQ: Proposed making 9.3 a P3.
GR: The navigable view should be synchronized with the main view to be most useful.
IJ: I suggest that this is a technique for 9.6.
DC: I think 9.3 needs to be a P2.
HR: I have a problem splitting the navigation part and the view part.
Resolved:
a) Leave 9.3 as is (no longer for dependent UAs).
b) Take note from 9.3 and make this a P3 checkpoint.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#98p
IJ: Yesterday we changed 7.2 to: "Implement W3C specifications when they are appropriate for a task."
JT: I'm ok with this.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0234.html
Dropped. No change.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#100
IJ: I wanted to warn readers that for some checkpoints, mere mortals cannot verify them by observing behavior of the software.
DP: Should we list the checkpoints?
IJ: I think that's possible, but why?
IJ: Is it problematic that some of our requirements may not be easily answerable?
JT: It's inherent in this business.
DP: I have no objection to adding the note. In lieu of or in addition to, we could/should annotate the checkpoints that are difficult to evaluate.
HB: I think that this won't be consistent across technologies.
DC: I'm concerned that if that a feature is not easily noticeable (either by effect or cause), why is it in this document?
JT: The standard example is that AT must know the nature of the object with the current focus. That's provided through the standard API. There's no way to observe that short of software.
IJ: I mention this because I think that this will come back to "haunt" us. I wanted the WG to ack this somewhere.
Resolved: Add Ian's proposed note.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#101
"10.1 Provide information about content and viewport changes (to users and through programming interfaces). [Priority 1]:
DP: I propose to drop "and".
CMN: IE shows changes by changing highlight, scrollbars, etc.
Resolved: No change.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#102
JG: I reviewed this list last night. We've already dealt with some of them: language, speech playback, control rates, current view/viewport definitions.
JT: I want to drop the list.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#103
Resolved: Adopt Ian's proposal.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#104
JT: I like the proposal. I recommend that this be used with the other guidelines.
JB: Where would they make the checklist available? On their site? On the W3C site? The idea of supplying the checklist sounds good. We'll have to work out the detail about where the claim would reside, etc.
HB: I'd prefer that submitted checklists are annotated (to show interpretations made).
DC: Is there a problem if it's not self-evident that a checkpoint doesn't apply?
JB: I don't like the detail of having to list all the checkpoints. I think it may be difficult to come up with clean "groupings" for user agent classes. But this won't be the only one. It's hard to come up with stable profiles. Other W3C WGs have tried to come up with profiles and failed.
DB: Legal issues - providing detail about where you comply may be used as evidence. I'd have to talk with lawyers.
GR: Need boilerplate disclaimer if evaluations posted on W3C site. Companies should get these evaluations.
JB: W3C would not put definitive reviews unless we couldn't get the organization to do it. We would document that there was not reply from the organizations.
GR: In my reviews, I documented how using one particular screen reader would change the conformance situation.
Resolved:
1) Adopt Ian's proposal (software version/OS, date).
2) Action Ian: Propose how the checklist will be delivered.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#105
JG: Issues:
MQ: I don't think that accesskeys should focus + activate.
JT: I wish that this had been done in HTML 4.0 correctly... Given the disaster, I propose these resolutions:
MN: Please consult the CSS3 WD [1], [2] for information about keyboard control. This WG should ensure that what we discuss is consistent with those developments.
[1] http://www.w3.org/TR/1999/WD-css3-userint-19990916
[2] http://www.w3.org/TR/1999/WD-css3-userint-19990916#keyboard
JT: Note the problem in the definition of [2]:
"Key-equivalents are active in a document only if an element inside the document has the focus (this can include BODY)."
JT: This is not what we say in UAGL.
IJ: I think this is a mistake and they mean that configs only apply when in a particular viewport.
JG: Summarizing - we need to ensure compatibility with other W3C specs.
DP: I don't think pointing to HTML 4 or CSS3 is sufficient. The way it's defined in HTML 4 is too vague - it's broken. Not clear whether focus + activate or just activate or just focus. I want to look in particular at checkpoint 2.5 but also keep in mind where accesskey should be stressed in the techniques or other checkpoint notes.
DB: Authors should indicate what accesskeys they provide.
GR: You can't use Alt-H and Alt-F accesskeys in IE 4/5 since they're overridden by IE.
TL: I think it's important to be platform and browser-independent in resolving this issue. This WG should not try to fix the problem (since out of scope). Also, don't rely on HTML 4 or CSS 3 alone since they, too, will pass.
CMN: I agree with TL. Accesskeys provide hints to the UA. It's the responsibility of the UA to use that information to construct a different user interface. Thus, authors shouldn't have to always document their access keys. In fact, the UA may remap the access keys. The author has no guarantee about how the UA will handle the accesskeys.
TL: I agree with CMN. If you can successfully remap the author-supplied interface to the UI, you've solved a lot of problems.
MQ: At Productivity Works, we do this. The user can customize the keyboard configuration. The help files are updated on the fly.
RS: We shouldn't specify accessibility requirements on something this poorly defined.
DC: I think 2.4 to 2.8 should be P3.
CMN: I don't agree.
DB: Just because you can't configure the UA doesn't mean you can't get at the UA.
DP: There are some tools that capture the functionalities intended in 2.4 - 2.8.
Issue for 2.5: Implied here that author-supplied key configs override UA configs. But it's not clear that UAs do this consistently.
DC: I don't think there's any problem with the current 2.5.
HR: I think we need to ensure that the user have access to all keys specified by the author (however that's resolved - either what the author specified, how they're remapped, etc.).
RS: If you're going to keep 2.5, keep statements like "Can't override the default UA configuration or system keyboard configs."
Action GR: Repropose 2.5 so that it's clear that there should be a cascade order whereby the user has ultimate control or can concede control to the tool.
Resolved: Since HTML 4.0 doesn't specify focus + activate behavior sufficiently, the WG won't try to fix.
Issue: Should 2.3 include author-specified key bindings?
CMN: I think 2.3 already includes author-specified key configs.
DB: I don't think this should be P1 for the UA.
JT: You can get at all active elements through serial navigation. So you don't need to make direct access a P1.
CMN (Summarizing/Proposing)
DB: I think that documentation of defaults should be P1 but that documentation of author-specified configs should be P3.
RS: Accesskey doesn't let you describe the functions. So how does the UA document the access keys? Therefore I agree with DB.
CMN: I think should be P2 to document keyboard configs.
JT: I think it's problematic to put P2 on something poorly specified.
DC: I have a problem with how we're missing content with UA functionalities.
Resolved: Copy 8.4 to new checkpoint, removing "just" and making it a P1. (Leave 8.4 as P2).
MN: Note that in DOM2, all elements can take the focus.
CMN: Then our definition of active elements is broken.
Action MN: Propose a new definition of active element.
IJ: Is there a requirement for "Direct access to active elements."
JT: No.
JG: This was decided a long time ago.
IJ: How much should author and UA configs be conflated in documentation of current config?
CMN: Most important is to document "what works at the moment?"
CMN/TL: Yes. The user doesn't need to know the difference.
Proposed: Make checkpoint 2.3 for author-specified only. Move to P3. "2.3 Provide information to the user about author-specified keyboard configurations."
HR: If this is done, move 2.3 to another guideline.
CMN: We're making the wrong split. There are two things we need to document:
a) How can I get at something somehow? Documentation of this is P1.
b) Other means for getting at the something. Documentation of these techniques is less important. I think it should be P2.
HR: I think that 2.3 should remain as is, for user agent-supplied current configuration. Move the author-supplied information somewhere else (lower priority).
DB: Propose that documentation of author-specified bindings be a separate checkpoint, P3.
DC: I think that display of P3 information as a P2 is logically inconsistent.
JT: Yes.
CMN: I don't think it matters who supplies the information. At the user end, what's important is how it works. As to how it can be P2 in UAGL and P3 in WCAG: providing direct access is like providing outline views. These are strategies for making access faster. Having the ability to do things more quickly than serially is quite important. Why are UA-supplied accesskeys more important than those that the author considers important? These are important, not just beneficial.
GR: I agree with CMN. I think that providing a list of accesskeys should have been a P3 in WCAG.
DB: We're talking about an author-specified alternative to getting at information they can get to in a standard way. It's beneficial, but not more.
MQ: Making it P3 says to the author that their accesskey was not important. It's frustrating if users don't know that keyboard behavior changes.
JT: Documenting direct access is important. But the implementations are so flaky, that it shouldn't be P2 today.
DP: I don't think that there needs to be matching priorities between WCAG and UAGL. I think that current keyboard config should be in a single checkpoint.
KB: I think ok to add "author-specified" to 2.3 and make P3.
DC: Don't remap keys without the user's knowledge. Notably if changes are to the default configuration.
RS: Can we say something about the poor specification of access keys?
DB: I think it's more important to talk about reconfiguration of the user agent's configuration. It's P1 to know what has changed in the UI if the change means you can't get at UA functionalities. Configuration should include on-the-fly documentation of the changes.
Proposed: "2.3 Provide information to the user about author-specified keyboard configurations. P3"
DP: There are some scenarios that aren't covered in the current proposal.
Action CMN: Write a proposal to address this issue.
/* Wilson Craig arrives */
The following are techniques 1.1 through 1.6 as transcribed at the User Agent Working group meeting:
Technique 1.1
Operating system and application frameworks provide standard mechanisms for providing navigation control to your application for standard input devices. In the case of Windows, OS/2, the X Windows System, and MacOS,GUI applications are provided this information through the messaging queue through the window manager. In the case of non-GUI applications, the compiler run time libraries provide standard mechanisms for recieving keyboard input in the case of desktop operating systems. Should you use an application framework such as the Microsoft Foundation Classes, the framework used must support the same standard input mechanisms.
When implementing custom GUI controls do so using the standard input mechanisms defined above. Examples of not supporting the standard input devices are:
Technique 1.2
When providing input control to document elements in your user agent ensure that you follow the techniques defined in technique section 1.1. Any output resulting from user actions should use the techniques defined in technique 1.6.
Technique 1.3
When creating or using installation software ensure that it is navigable using the techniques 1.1 and 1.6. Installation software includes normal program update mechanisms included during normal program operation.
Technique 1.4
When creating the user agent software, including installation and deinstallation, ensure that it can be configured using techniques 1.1 and 1.6.
Technique 1.5
Ensure that the user can access user agent documentation using the User Agent Accessibility Guidelines. A way to do this in Windows would be to create help files in HTML so that you can use a Windows browser designed to meet the User Agent Accessibility Guidelines. This HTML source would also need to follow the Web Content Accessibility Guidelines.
Technique 1.6
Operating system and application frameworks provide standard mechanisms for the use of standard output devices. In the case of common desktop operating systems, such as Windows, OS/2, and MacOS standard API are provided for writing to the display and the multimedia subsystems.
It is important to also support standard output notification of sound such as those found in the Windows control panel for sounds. Windows maps accessibility features to respond to the event caused by generation of these specific system sounds. Accessibility features such as show sounds would flash the screen, as appropriate, in response to events that would cause these sounds to play. This enables the deaf user to user your application in the absence of sound.
When implementing standard output you would not want to:
Here are some techniques for checkpoints 2.1 through 2.6.
Technique 2.1
Use the techniques in section 1.1 as they pertain to a keyboard input device.
Technique 2.2
Documentation for default keyboard commands should be provided in electronic format for direct access as defined in Technique 1.5. Keyboard commands should include but not be limited to shortcuts, accelerators, tab keys, and element activation keys.
Technique 2.3
Documentation for the current keyboard commands should be provided in electronic format for direct access as defined in Technique 1.5. Keyboard commands could change as a result of the addition of navigation bar tasks, addition of document defined accesskeys, and/or changing the default keyboard actions through a keyboard mapping facility. When constructing a keyboard mapping facility it is important to provide associated descriptions for the task being mapped.
Technique 2.4
A mechanism for allowing the user to configure the mapping of key strokes to user agent functionalities is to implement a keyboard mapping facility.
Technique 2.5
A mechanism to allow the user to turn on and off author-specified keyboard configurations is to add a checkbox in the keyboard mapping dialog to that would toggle the support for author-specified keyboard configurations. An example of author-specified keyboard configurations is the use of the HTML 4.0 accesskeys.
Technique 2.6
Platform conventions used to indicate which keys activate which user agent functionalities are using the shortcut key (mnemonics), and keyboard accelerators defined in standard controls. These are visually rendered using an underscore under a character in a menu item or button corresponding to the shortcut key activated with an ALT+character. For menu accelerators the text in the menu item is often followed by a CNTRL+function key. These are conventions used by the Sun Java Foundations Classes and Microsoft Foundations Classes for Windows.
Issue: Why is 4.1 a Priority 1? If you use a text-only browser, and the images slow download, this becomes an accessibility issue.
Resolved: Make 4.1 a Pri 3.
Resolved: Add a note to 3.1 about ensuring that alt content available when primary content turned off.
Proposed: Generalize 3.8 to apply to more than just continuous tracks : all sources of alt content.
Action Ian: Propose on the list.
Resolved: Clarify that G4 is about author-supplied resources.
Resolved: Drop 4.5 since covered by 3.8 (case of zero tracks selected).
Resolved: Drop 4.9/4.10 since covered by new checkpoint for choosing from among style sheets.
Issues surrounding techniques for turning on/off content:
Start with assumption that alt info is available.
Not downloading:
Formatting:
DB: I don't think we should be telling developers how to do something in the UI. I think the techniques should tell developers what issues may arise when they do something.
HR: Do we need a particular checkpoint for background sounds? There is one for background images, why not one for sounds?
DB: Sounds are in one plane (you hear all sounds together).
GR: I agree with HR. Some content is delivered with real audio. If you're using synthesize, there may be clashes with the device.
Proposed: Add a checkpoint to turn on/off background sounds.
Action Ian: Propose on the list.
Background images:
7.1 Implement the accessibility features defined for supported specifications. [Priority 1]
JT: I have problems with the term "all".
CMN: So say "Refer to section so and so".
7.2 Support appropriate W3C Recommendations. [Priority 2]
8.1 Allow the user to navigate viewports (including frames). [Priority 1]
8.2 For user agents that offer a browsing history mechanism, when the user returns to a previous view, restore the point of regard in the viewport. [Priority 1]
8.3 For dependent user agents only. Allow the user to navigate just among table cells of a table (notably left and right within a row and up and down within a column). [Priority 1]
IJ: May be deleted if we adopt table proposal.
(If we keep in appendix, keep in appendix?)
8.4 Allow the user to navigate just among all active elements. [Priority 2]
8.5 Allow the user to search for rendered text content, including alternative text content. [Priority 2]
8.6 Allow the user to navigate according to the structure of the resource. [Priority 2]
8.7 Allow the user to configure structured navigation. [Priority 3]
DB: What does this mean?
WC: If you're going to allow people to jump to elements by type, they may want to jump by default to some types, or to skip some types. E.g., read only headers.
9.1 Provide a mechanism for highlighting and identifying (through a standard interface where available) the current viewport, selection, and focus. [Priority 1]
9.2 For dependent user agents only. Provide the user with information about the number of viewports. [Priority 2]
9.3 For dependent user agents only. Allow the user to view an outline of a resource constructed from its structural elements (e.g., from header and list elements). [Priority 2]
9.4 Describe a selected element's position within larger structures (e.g., numerical or relative position in a document, table, list, etc.). [Priority 2]
9.5 For a selected link, indicate whether following the link will involve a fee. [Priority 2]
IJ: Micropayments spec doesn't talk about rendering.
[and!]
*enable announcing of payment obligation incurred by micropayment link activation with an option to remove focus without commiting
9.6 For a selected link, provide information to help the user decide whether to follow the link. [Priority 2]
[or!]
9.7 Allow the user to configure what information about links to present. [Priority 3]
9.8. Provide a mechanism for highlighting and identifying (through a standard interface where available) active elements. [Priority 3]
9.9. For dependent user agents only. Provide access to header information for a selected table cell. [Priority 1]
9.10 For dependent user agents only. Indicate the row and column dimensions of a selected table. [Priority 3]
9.11 Provide information about form structure and navigation (e.g., groups of controls, control labels, navigation order, and keyboard configuration). [Priority 2]
9.12 Maintain consistent user agent behavior and default configurations between software releases. Consistency is less important than accessibility and adoption of system conventions. [Priority 3]
10.1 Provide information about content and viewport changes (to users and through programming interfaces). [Priority 1] (Checkpoint 10.1 in guidelines)[23]
Techniques are in section 3.6.8 Scripts
NB: JT is not comfortable that the notification is always so important anyway
10.2 Ensure that when the selection or focus changes, it is in the viewport after the change. [Priority 2] (Checkpoint 10.2 in guidelines)[24]
Techniques are in section 3.4.2 Tracking selection and focus
10.3 Allow the user to selectively turn on and off notification of common types of content and viewport changes. [Priority 3] (Checkpoint 10.3 in guidelines)[25]
Techniques are in section 3.6.8 Scripts
10.4 When loading a resource (e.g., document, video clip, audio clip, etc.) indicate what portion of the resource has loaded and whether loading has stalled. [Priority 3] (Checkpoint 10.4 in guidelines)[26]
Techniques are in section 3.6.1 Status information
10.5 Indicate the relative position of the viewport in a resource (e.g., the percentage of the document that has been viewed, the percentage of an audio clip that has been played, etc.). [Priority 3] (Checkpoint 10.5 in guidelines)[27]
Techniques are in section 3.6.1 Status information
10.6 Prompt the user to confirm any form submission triggered indirectly, that is by any means other than the user activating an explicit form submit control. [Priority 2] (Checkpoint 10.6 in guidelines)[28]
Techniques are in section 3.6.6 Form controls
Guideline 11[29]:
11.1 Allow the user to configure the user agent in named profiles that may be shared (by other users or software). [Priority 2] (Checkpoint 11.1 in guidelines)[30]
Techniques are in section 3.8.1 User profiles
11.2 Allow the user to configure the graphical arrangement of user interface controls. [Priority 3] (Checkpoint 11.2 in guidelines)[31]
Techniques are in section 3.8.3 User interface
Guideline 12[32]:
12.1 Provide a version of the product documentation that conforms to the Web Content Accessibility Guidelines. [Priority 1] (Checkpoint 12.1 in guidelines)[33]
Techniques are in section 3.9.2 Accessible documentation
DB: I think this checkpoint is too specific to HTML (since WCAG very oriented towards HTML). I don't think that these guidelines should dictate that help be in HTML.
CMN: A document does not have to be HTML to conform to WCAG.
DB: Old Windows Help was in many ways more accessible than current HTML.
DB: I'll go back and look at WCAG. I think that there's an issue here.
Resolved: No change for now.
12.2 Ensure that all user agent functionalities that promote accessibility are documented. [Priority 1] (Checkpoint 12.2 in guidelines)[34]
Techniques are in section 3.9 Documentation
12.3 Describe product features known to promote accessibility in a section of the product documentation. [Priority 2] (Checkpoint 12.3 in guidelines)[35]
Techniques are in section 3.9.1 Where to document accessibility
JG: In closing:
Meeting adjourned 5:00pm local time