- From: Hansen, Eric <ehansen@ets.org>
- Date: Thu, 10 May 2001 10:06:54 -0400
- To: "'Ian Jacobs'" <ij@w3.org>, w3c-wai-ua@w3.org, tantek@cs.stanford.edu
I am grateful for Tantek's very thoughtful review and the proposals
resulting from Ian's discussion with Tantek. Below are some comments:
> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Tuesday, April 24, 2001 6:38 PM
> To: w3c-wai-ua@w3.org; tantek@cs.stanford.edu
> Subject: [Review] Tantek Çelik / Ian Jacobs comments on 9 April 2001
> UAAG 1.0 (Part I)
>
>
> Hello,
>
> Tantek Çelik and I spent eight hours on 22 April reviewing the 9
> April 2001 (last call) draft of UAAG 1.0. [1]. Tantek develops IE
> for the Mac and participates in the W3C CSS Working Group. Tantek
> and I last reviewed UAAG 1.0 together in early July 2000 (see
> notes [2], [3]). I am very pleased to report that Tantek found
> the 9 April draft much improved, and we encountered few issues
> and ambiguities that I would consider substantial. Tantek also
> had some great ideas for improving the usability of the document
> (which he claims to have come up with after reading WCAG 1.0, so
> there was lots of mutual patting on the back <wink>).
>
> The issues below are not formal last call issues raised by
> Tantek. The bulk of the comments come from Tantek, but this is my
> own presentation (and filtering) of the discussion. I have also
> included some comments from me that are related to the discussion
> or are the result of further reflection.
>
> This is the first of three emails:
>
> 1) Part one is the most important issues
> 2) Part two is about minor clarifications
> 3) Part three is about good ideas to improve the usability
> of the document.
>
> I have not reported editorial issues, which I will simply correct
> for the next draft.
>
> Many thanks to Tantek for taking the time to scrutinize the
> document!
>
> - Ian
>
> P.S. Tantek did not sign off on this email or the other two. He
> said he trusted me to communicate our conversation to the
> Working Group.
>
> [1] http://www.w3.org/TR/2001/WD-UAAG10-20010409/
> [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0060
> [3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0068
>
> ================================
> 1) Checkpoint 1.2: "Start" events are more important than "End"
> events.
> ================================
>
> Many input device events in today's systems are designed as
> start/end pairs. Examples include: mousedown/mouseup,
> mouseover/mouseout, and key down/up. These events are (to my
> understanding) always expected to happen in pairs. Tantek made
> the point that designers therefore make assumptions that an "end"
> handler will not be executed without execution of a preceding
> "start" handler. Checkpoint 1.2 as written breaks this model.
>
> --------
> Proposal
> --------
>
> Narrow checkpoint 1.2 so that the list of handlers that the user
> agent makes available may vary according to different states. In
> particular, the user agent should not be required to allow the
> user to trigger an "end" handler prior to execution of the
> corresponding "start" handler. Similarly, the user agent should
> probably not allow the user to trigger another start handler
> until the preceding end handler of the same type has been
> triggered.
>
> Summary: The user agent should only have to support the sequences
> that are available to the user of the native input device (e.g.,
> mouse).
>
> There would probably need to be some changes to checkpoint 9.4 as
> well, at least to clarify that the "list of available handlers"
> may not be the full list due to the current state of interaction
> (i.e., you may only get start handlers, not end handlers).
>
> A technique idea: Allow the user to trigger two "start" handlers
> in a row (of the same type) and trigger the intervening "end"
> handler automatically just before the second "start" handler.
>
EH: Sounds reasonable.
> ========================================
> 2) Checkpoint 2.1: Do some UAAG 1.0 requirements override this?
> ========================================
>
> Checkpoint 2.1 says "render according to spec". However, some of
> the requirements in Guideline 3 (and possibly others) require
> control of rendering that may not be part of a specification or
> may even "contradict" a specification. [Al Gilman has said that
> if a W3C specification does not allow the type of control
> required by Guideline 3, it is broken. But UAAG 1.0 is not just
> for user agents rendering content authored using W3C
> specifications.]
>
> --------
> Proposal
> --------
>
> State clearly in checkpoint 2.1 that for other rendering
> requirements elsewhere in the document:
>
> a) If the format spec explains how to provide the
> control we require, follow the spec.
>
> b) If the required control does not contradict the
> format specification, there is no problem implementing
> the required control features. [The fact that the
> specificatino says nothing does not mean that the
> additional control requirements of UAAG 1.0 do not apply!]
>
> c) If the required control does contradict the format
> specification, it is acceptable to violate 2.1 in order to
> satisfy the other rendering requirements of UAAG 1.0.
>
> I don't think that the other direction should be permissible:
> the UA should not be permitted to conform to UAAG 1.0 by
> satisfying 2.1 and by not satisfying the other rendering
> requirements. I would guess that in this case, the format
> spec probably doesn't satisfy the requirements of checkpoint
> 8.2 as it would seem to prevent the authoring of content that
> conforms to WCAG 1.0.
EH: Seems to make sense. But some variation of the paragraph above seems
important to clarify the rationale.
>
> ========================================
> 3) Checkpoint 2.2: Define text format more formally.
> ========================================
>
> Checkpoint 2.2 says that text formats "include at least the
> following". This is an unbounded requirement as written.
>
> --------
> Proposal
> --------
>
> Change checkpoint 2.2 to define exactly what we mean by text
> formats for this document (i.e., the minimal requirement). For
> example, change the phrase to "For the purposes of this
> checkpoint, text formats are:...".
>
EH: OK
> ========================================
> 4) Checkpoint 2.3: Scope of "alert" requirement.
> ========================================
>
> Checkpoint 2.3 requires the user to "alert the user to the
> existence of the [unrendered conditional] content and provide
> access to it."
>
> Is the alert requirement global (i.e., "there is conditional
> content in this page") or element-level?
>
> If the alert requirement is global, I think that a technique that
> is just as good as an alert is the ability to query the document
> and ask "Is there conditional content in this page?".
>
> If the alert requirement is element level ("there is conditional
> content here") this needs to be clarified.
>
> I would like the Working Group to clarify which is intended.
>
EH: Worth discussing.
> ========================================
> 5) Configuration not required when the user agent always or
> never does something?
> ========================================
>
> Many of the checkpoints involve configuration
> requirements. However, configuration may not be necessary if the
> user agent always or never provides the critical functionality in
> question.
EH: Very good point.
We've already incorporated this idea into checkpoint
> 5.1, which reads:
>
> "5.1 ... Configuration is not required if the current focus can
> only ever be moved by explicit user request."
>
> --------
> Proposal
> --------
>
> Modify the configuration checkpoints as follows:
>
> a) No configuration is necessary if the user agent always provides
> the required functionality: 2.3, 2.5
EH: Sounds reasonable.
>
> 5.4, 5.5: I'm not sure about these two. If it's an extra
> effort to confirm a prompt, then maybe configuration is
> required.
EH: I am inclined to keep configuration for 5.4 and 5.5.
>
> b) No configuration is necessary if the user agent never
> provides the functionality: 5.1, 5.2
EH: Ok.
>
> For checkpoints 3.2, 3.4, and 3.7, no configuration is
> necessary for the placeholder or alert parts (the UA
> does the right thing by always providing placeholders in this
> case, and always alerting in this case).
>
> c No changes to the following checkpoints (i.e., configuration is
> required). In each case, there is a phrase of rationale:
>
> 2.4: User may also want automatic rendering.
> 2.7: User may not want repair text.
> 2.8: Two options here, so configuration required.
> 2.9: User may not want automatic rendering.
> 2.10: User should have access to all content.
> 3.1: User should have access to all content.
> 3.2: User may also want automatic rendering.
> 3.3: Some users may find blinking important or useful
> (e.g., users with deafness).
> 3.4: User should have access to all content.
> 3.5, 3.6: Automatic behavior also desirable.
> 3.7: User should have access to all content.
> 4.1, 4.2, 4.3, 4.9, 4.11, 4.13, 4.14:
> More than one on/off setting required.
> 5.3: May want automatic opening behavior.
> 5.6: May want automatic closing behavior.
> 9.5: May want automatic closing behavior.
> 9.9: More than one on/off setting required.
> 10.2, 10.4: More than one on/off setting required.
> Guideline 11: More than one on/off setting required.
> 12.4: Documentation checkpoint (not about configurability).
>
> ================================
> 6) Checkpoint 2.9: Automatic rendering of all conditional content
> at once required?
> ========================================
>
> Checkpoint 2.9 reads:
>
> "Allow configuration to render all conditional content
> automatically. Provide access to this content according to
> format specifications or where unspecified, by applying one of
> the following techniques described in checkpoint 2.3: 1a, 2a,
> or 1b."
>
> I don't think it's necessary that all conditional content be
> rendered automatically in the same viewport at the same time. I
> think that it would suffice to have one or more configurations
> that allow all conditional content to be rendered automatically
> in some viewport at some time. For instance, one setting to
> render NOFRAMES content automatically in HTML, another to render
> NOSCRIPT content automatically, etc.
>
> --------
> Proposal
> --------
>
> <NEW 2.9>
> Allow configuration to render all conditional content
> automatically. Provide access to this content according to
> format specifications or where unspecified, by applying one of
> the following techniques described in checkpoint 2.3: 1a, 2a, or
> 1b. The user agent is not required to satisfy this checkpoint by
> rendering all conditional content automatically in a single
> viewport at one time. The user agent may satisfy this checkpoint
> by allowing different configurations to render different types of
> conditional content automatically, possibly in different viewports.
> </NEW 2.9>
>
EH: Sounds reasonable.
> Comments:
>
> - Tantek asked whether alternative style sheets should be
> considered conditional content. I didn't think so at first, but
> the more I think about it, the more I think they should be
> considered conditional content. The definition of conditional
> content starts:
>
> "Conditional content is content that, by specification, should
> be made available to users through the user interface, generally
> under certain conditions (e.g., user preferences or operating
> environment limitations)."
>
> Checkpoint 4.16 requires that the user be able to choose from
> available author style sheets, which includes alternative style
> sheets. I note that the definition says "user interface" rather
> than "viewport" specifically (where *content* is rendered).
>
> The proposed change to 2.9 is consistent with providing
> alternative style sheets one at a time (instead of all at once,
> automatically) as required by 4.16.
EH: I think that this would be an expansion of our intent. I am really not
sure of the consequences of such an expansion. This gets back to what is
"content" and what is its relationship to the DOM.
>
> ========================================
> 7) Definitions of rendered content / viewport circular.
> ========================================
>
> The current circular definitions say "rendered content is content
> available through a viewport" and "the viewport is where the user
> agent renders content".
>
> --------
> Proposal
> --------
>
> <OLD RENDERED CONTENT>
> Rendered content is the part of content capable of being
> perceived by a user through a given viewport (whether visual,
> auditory, or tactile).
> </OLD RENDERED CONTENT>
>
> <NEW RENDERED CONTENT>
> Rendered content is the part of content that the user agent makes
> available to the user's senses of sight, hearing, or touch (and
> only those senses for the purposes of UAAG 1.0). Any content that
> causes an effect that may be perceived through these senses
> constitutes rendered content. This includes text characters,
> images, style sheets, scripts, and anything else in content whose
> effect when processed may be perceived.
> </NEW RENDERED CONTENT>
>
> At first, I was nervous about this model, but I am unable to draw
> a line between style sheets, text content, and binary image
> formats: they all require processing to create an effect that is
> perceived by the senses. It's easiest to say that when they cause
> an effect that may be perceived (by some users, but not
> necessarily by all), they are rendered content. Some examples of
> content that is generally not rendered: comments. They may be
> rendered in the source view.
EH: Does content include algorithms for sequencing and branching? They can
create effects than can be sensed via visual, auditory, or tactile senses
(e.g., computer games).
>
> The only checkpoints that have requirements related to rendered
> content are 2.3 and 10.9, and this model is consistent with those
> requirements. The definition of "point of regard" refers to
> rendered content and is used in 9.3; the usage is also consistent
> there.
>
> <NEW VIEWPORT>
> The user agent renders content through one or more viewports.
> </NEW VIEWPORT>
>
> <OLD VIEWPORT>
> The user views rendered content through a viewport.
> </OLD VIEWPORT>
EH: Seems reasonable.
>
> Comment: I was thinking about the HTML TITLE element, which most
> user agents render in a title bar, separate from the "main"
> viewport of the user interface. Should the title bar be
> considered a viewport? I think it should. The only checkpoint
> that makes me nervous with this approach is 9.1:
>
> "9.1 Allow the user to make the selection and focus of each
> viewport (including frames) the current selection and current
> focus, respectively."
>
> See the next issue as a way to address this.
>
> ========================================
> 8) Require focus for enabled elements only. Don't require
> selection. Clarify that "user interface focus" is not related
> to viewports (but instead to other controls of the user
> interface).
> ========================================
>
> My discussions with the SVG Working Group, and the previous issue
> in this email lead me to the following proposal regarding focus
> and selection requirements.
>
> --------
> Proposal
> --------
>
> - We should explicitly not require user selection for
> conformance. I think that stating this explicitly is not a
> significant departure from the way that the following checkpoints
> involving selection are written: 6.5, 7.1, 9.1, 9.3, 9.7, 10.2,
> 10.3, 10.8.
>
> - We should explicitly require content and user interface focus
> for conformance, but only when there is something to focus on
> (either an "enabled element" or a user interface control).
>
> To implement this proposal:
>
> 8a) Fix 9.1, which is broken in a number of ways (that are not
> really serious):
>
> <NEW 9.1a>
> Allow the user to make the selection of each viewport (including
> frames) the current selection. For content only.
> Note: UAAG 1.0 does not require a conforming user agent to
> implement a user selection. The selection requirements of this
> document only apply when the user agent implements a selection.
> </NEW 9.1a>
>
> <NEW 9.1b>
> Implement one content focus for each viewport where
> enabled elements are part of the rendered content. Allow the user
> to make the content focus of each viewport (including frames) the
> current focus. For content only.
> Note: UAAG 1.0 assumes that a viewport has at most one content
> focus. The requirements of this document should still make
> sense for viewports with more than one focus.
> </NEW 9.1b>
>
> <NEW 9.1c>
> Implement a user interface focus mechanism. Allow the user
> to move the user interface focus to any enabled user interface
> control. User agent only.
> </NEW 9.1c>
>
> Comment on 9.1c: This is like checkpoint 9.2, but for the UI.
>
EH: What priorities for the foregoing?
> 8b) Add an applicability provision related to selection:
>
> "A checkpoint (or part of a checkpoint) applies unless any one
> of the following conditions is met:"
>
> <NEW CONDITION>
> The checkpoint makes requirements about the selection, but the user
> agent does not implement a user selection mechanism.
> </NEW CONDITION>
>
> 8c) Checkpoint 9.3: I think that the "user interface focus"
> should *not* be associated with the viewport for any requirements
> in the document, including for checkpoint 9.3. The user
> interface focus is set on other controls of the user
> interface. Therefore, I think that checkpoint 9.3 should not
> include "user interface focus" in the list of state information
> that must be part of the *viewport* history.
EH: Sounds reasonable.
>
> 8d) Change 5.1 so that "current focus" (which includes both
> content focus and UI focus) does not refer just to viewports.
>
EH: I wonder if the definition of focus needs to be clarified in the
document.
Old:
In this document,the unmodified term "focus" means both "content focus" and
"user agent focus".
When several viewports coexist, at most one viewport's content focus or user
interface focus receives input events; this is called the current focus.
I am not sure if BOTH means SIMULTANEOUS or not.
New:
In this document,the unmodified term "focus" means SIMULTANEOUS "content
focus" and "user agent focus".
When several viewports coexist, at most EITHER one viewport's content focus
or ONE user interface focus receives input events; this is called the
current focus.
=
Maybe I am misinterpreting, but I think this could be clarified.
> <OLD 5.1>
> Allow configuration so that the current focus does not move
> automatically to viewports that open without explicit user
> request.
> </OLD 5.1>
>
> <NEW 5.1>
> Allow configuration so that the current content focus does not
> move automatically to viewports that open without explicit user
> request.
> </NEW 5.1>
>
> Comment: I'm not sure whether 5.1 *should* include a requirement
> about not moving user interface focus. What would the user
> agent do in the case of prompts? Would there be a configuration
> so that the focus would not move to prompts, e.g., to confirm
> a form submission?
EH: This concern is one that I have had but not been able to articulate.
Probably deserves discussion.
>
> 8e) Leave 5.2, 10.7 as is.
>
> 8f) Fix 10.8. It should be about content only.
EH: Seems reasonable.
>
> 8g) Fix definitions of focus, selection, and viewport. In
> particular, mention that for UAAG 1.0 there is expected to be
> only one of each (but one could imagine an operating environment
> or user agent with two focuses per viewport, etc.).
>
> ================================
> 9) Checkpoint 2.10: Is this only about natural language? Or is
> this also about scripts?
> ================================
>
> Checkpoint 2.10 reads:
>
> "Allow configuration not to render content in unsupported
> natural languages."
>
> --------
> Proposal
> --------
>
> I think this requirement needs to mention unsupported scripts
> (writing systems) explicitly.
>
> <NEW 2.10>
> "Allow configuration not to render content in unsupported natural
> languages and scripts (writing systems)."
> </NEW 2.10>
>
EH: Ok.
> ================================
> 10) Checkpoint 4.1: Is access to very small fonts a P1
> requirement?
> ================================
>
> I think it's a P1 requirement to increase the text size (for
> users with low vision). I don't think it's a P1 requirement to
> shrink the text size to an arbitrarily small value. Gregory has
> said in the past that very small fonts allow him to fit more
> content on a page and reduce scrolling. But that's not a P1 issue
> (that's more like a P3 issue). An analogy: checkpoint 4.4 only
> requires slowing of presentations, not speeding up, which we did
> not consider a P1 requirement.
>
> --------
> Proposal
> --------
>
> <OLD part of 4.1>
> Allow the user to choose from among the full range of font sizes
> supported by the operating environment.
> </OLD part of 4.1>
>
> <NEW part of 4.1>
> Allow the user to choose from among the full range of font sizes
> above 9 pixels supported by the operating environment.
> </NEW part of 4.1>
>
EH: Seems reasonable.
> ================================
> 11) Checkpoint 4.9: Clarification that global volume control is for
> content and user agent sounds.
> ================================
>
> Checkpoint 4.9 starts:
>
> "Allow global configuration and control of the volume of all
> audio, with an option to override audio volumes specified by the
> author or user agent defaults."
>
> --------
> Proposed
> --------
>
> The user agent may satisfy this requirement by providing a single
> control over all sounds, whether they come from content or the
> user interface. Distinct volume control for content as opposed to
> UI is not required.
>
> Clarify that the global system volume would satisfy this
> checkpoint (a little stronger than the current Note).
EH: Ok.
>
> ================================
> 12) Checkpoint 4.10: P1 for non-style, P2 for style
> ================================
>
> Checkpoint 4.10 reads:
>
> "Allow independent control of the volumes of distinct audio
> sources synchronized to play simultaneously."
>
> --------
> Proposed
> --------
>
> 12a) For consistency with checkpoints 4.4 and 4.5, checkpoint 4.10
> should include the following statement:
>
> "The user agent is not required to satisfy this checkpoint for
> audio whose recognized role is to create a purely stylistic
> effect."
>
> 12b) There should be a new P2 checkpoint for volume control
> of other audio content.
>
EH: Ok.
> ================================
> 13) Checkpoint 6.4: Not always obvious to distinguish access
> from a Web page from plug-in access.
> ================================
>
> Tantek had the same reaction as the AOL reviewers [4] that 6.4 as
> written may pose some security risks (write access to all user
> interface controls). I suggested that access for plug-ins should
> be provided, but not for authors (from Web pages). He said that
> it's not always easy (or possible?) to distinguish the two,
> notably in the javascript case. I don't know how to address this
> one and need developer input.
>
> [4]
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0068
>
EH: Deserves discussion.
> ================================
> 14) Checkpoint 7.3: What if OS conventions are inferior to what
> the user agent developer would implement?
> ================================
>
> "What if I can do better than the standard or convention?" has
> been a recurring comment on all of our checkpoints that involve
> following conventions, including:
>
> 6.4, 6.5, 6.6: Standard APIs
> 7.1, 7.2, 7.3, 7.4: Operating environment conventions
>
> There may be others as well (e.g., 8.1).
>
> Jon commented on this in a recent email [5]:
>
> "My main concern is that we want to reduce the reliance on
> proprietary or special solutions for individual assistive
> technologies, since this will make it harder for developers to
> make their software accessible and a smaller number of
> assistive technologies may be supported."
>
> [5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0070
>
> The argument for conventions is predictability and
> interoperability. Our checkpoint 7.3 is a Priority 2, since not
> following conventions doesn't necessarily make access impossible.
> I find compelling the AOL [4] suggestion that is consistent with
> this that it's a P1 requirement to make it work, and a P2
> requirement to follow standards and conventions.
>
EH: This is a very interesting question and a tough belancing act.
> I hope we will have further discussion on this topic so that we
> can establish a consistent model in the document, and where there
> are exceptions, we have rationale to back them up.
>
> ================================
> 15) Definition of "non-interactive element",
> checkpoints 9.2 and 9.6
> ================================
>
> Tantek did not like the definition of "disabled" element as any
> element that is not enabled. This means that a paragraph of text,
> which might never be enabled in any session, would be considered
> a disabled element.
>
> Instead, he proposed adding a definition of "non-interactive
> element". Please consider this definition:
>
> "A non-interactive element is piece of content that, by
> specification, is not expected to be an enabled element in
> any user session."
>
> The definition of disabled element would become:
>
> "A disabled element is an element that is not enabled
> in the current user session but could be in some user
> session."
>
> Non-interactive elements might be enabled in some sessions
> because of how the user agent chooses to handle them.
EH: Need an example of this.
>
> The following checkpoints would be changed accordingly:
>
> <OLD 9.2>
> The user agent may also include disabled elements in the
> navigation order.
> </OLD 9.2>
>
> <NEW 9.2>
> The user agent may also include disabled and non-interactive
> elements in the navigation order.
> </NEW 9.2>
>
> <OLD 9.6>
> The user agent must not include disabled elements in the
> navigation order.
> </OLD 9.6>
>
> <NEW 9.6>
> The user agent must not include disabled elements or
> interactive elements in the navigation order.
> </NEW 9.6>
EH: Changes seem reasonable.
>
> ================================
> 16) Checkpoint 9.5: Moving focus without triggering handlers
> may be wrong.
> ================================
>
> Tantek argued that:
>
> a) If there are no focus handlers on a page, this is not necessary.
> b) If there are no focus handlers on a page, not firing them
> may break the page.
EH: Ian, is the above quote correct? "If there are no focus handlers on a
page"..?
>
> We did not discuss the technical feasibility, only whether it was
> a good idea at all.
>
> This functionality (like others in our document) does not
> guarantee access, and it may even break some pages. Still, it may
> enable access in some cases where access would not otherwise be
> possible. Perhaps the best approach is to get more experience
> with implementations of this checkpoint and see if it's actually
> usage.
>
> A good place to start is to design a test case where we think
> that not firing an onfocus handler automatically would improve
> access (in conjunction with the other checkpoints for manual
> firing).
EH: Maybe I don't fully grasp this. Needs further discussion.
> ================================
> 17) Checkpoint 10.1: "Purpose of table" is vague.
> ================================
>
> Tantek found the phrase "purpose of each table" to be too
> vague. Perhaps we should add a parenthetical such as
> "(e.g., as expressed in a summary or caption)".
EH: Ok.
>
> ================================
> 18) Checkpoint 10.3: What is relationship between black and
> white, and color?
> ================================
>
> This checkpoint reads:
>
> "10.3 Ensure that all of the default highlight styles for the
> selection, content focus, enabled elements, recently visited
> links, and fee links (1) do not rely on color alone, and (2)
> differ from each other, and not by color alone."
>
> What if the content is being rendered in black and white (or more
> likely, different pieces of content are being rendered in
> different shades of grey)? This checkpoint is designed so that
> users with some color deficiencies can hope to distinguish
> selection from focus, etc. by default. Can users with color
> deficiencies distinguish black from grey? (Obviously, it would
> be hard for anyone to distinguish two similar shades of grey. We
> don't talk about "contrast" in any of the checkpoints, because we
> don't have any requirements that rely on color by default.)
>
> I don't know whether "greying out" disabled elements would be
> considered a sufficient mechanism for distinguishing, for
> example, "enabled" from "disabled" elements. Similarly, is a
> "bold" font distinguishable from "regular" font?
>
> --------
> Proposal
> --------
>
> State explicitly in the Techniques document that "greying" alone
> is considered an effect that relies on color.
>
EH: Deserves discussion.
> Comment: I do not have the technical expertise to back up this
> statement, since I'm not a color expert (or a low vision
> expert). However, I think that this question reveals that our
> requirements stop at "color" and don't get into issues of
> contrast, saturation, hue, etc. Information at "The Lighthouse"
> about color contrast [6] suggests, however, that the above
> statement is on the right track. Here's a quote:
>
> "Don't assume that the lightness you perceive will be the same
> as the lightness perceived by people with color deficits. You
> can generally assume that they will see less contrast between
> colors than you will. If you lighten your light colors and
> darken your dark colors, you will increase the visual
> accessibility of your design."
>
> [6] http://www.lighthouse.org/color_contrast.htm
>
> =======================================================
> 19) Checkpoints 10.2, 10.4, 10.7: "Provide a mechanism",
> what must be done through the UI?
> =======================================================
>
> Can the technique to satisfy these checkpoints be through a style
> sheet? An initialization file? These are "mechanisms", even
> though they do not directly involve the user interface.
>
> The following paragraph from section 3.7 attempts to address
> which requirements must be met through the UI and which don't
> have to be:
>
> "The user agent must satisfy all requirements involving user
> interaction (both user input and output to the user) through
> the user interface of the subject of the claim. This includes
> not only the requirements that directly refer to to user
> control, configuration, etc., but also requirements that
> indirectly involve the user interface (e.g., system
> conventions pertaining to the user interface)."
>
> I am afraid that this paragraph might not be sufficient. For
> instance, it should be possible to satisfy many of the
> "configuration" requirements through configuration files (indeed,
> checkpoint 11.5 makes a "profile" requirement so I hope that
> these requirements can be satisfied through config files!).
>
> --------
> Proposal
> --------
>
> 19a) Add the following statement after the paragraph of section
> 3.7:
>
> "The user agent may satisfy the configuration requirements
> of this document through configuration files (e.g.,
> profiles). The user agent should (also) allow the user to
> configure the user agent through the user interface."
>
> 19b) Add statements to checkpoints 10.2, 10.4, and
> 10.7 that since the "mechanisms" themselves
> do not require user interaction, they can be implemented
> however the developer chooses. But the interaction part
> is subject to the paragraph from section 3.7.
>
EH: Probably reasonable, though not sure of all consequences.
> =======================================================
> 20) Checkpoint 12.1: Should be relative priority
> =======================================================
>
> Tantek supports the relative priority solution to the priority of
> this checkpoint.
>
> =======================================================
> 21) Checkpoints 12.2, 12.4, 12.5: Definition of features
> that benefit accessibility.
> =======================================================
>
> We need to harmonize what we intend by "features that benfit
> accessibility."
>
> The Note after 12.2 reads (12.5 is similar, 12.4 needs one too):
>
> "For example, review the documentation or help system to
> ensure that it includes information about the functions and
> capabilities of the user agent that are required by WAI
> Accessibility Guidelines, platform-specific accessibility
> guidelines, etc."
>
> In checkpoint 8.1 we state:
>
> "The accessibility features of a specification are those
> identified as such and those that satisfy all of the
> requirements of the "Web Content Accessibility Guidelines 1.0"
> [WCAG10]."
>
> --------
> Proposal
> --------
>
> 21a) In checkpoint 8.1, change the statement to:
>
> "For the purposes of this document, the accessibility features
> of a specification are those identified as such and those that
> enable the author to satisfy the requirements of the "Web
> Content Accessibility Guidelines 1.0" [WCAG10], whatever the
> priority."
>
> Editorial: Should this read "and those" or "or those"?
>
EH: Possible alternative wording:
"For the purposes of this document, the accessibility features
of a specification are those identified as such and those that
enable the author to satisfy ANY OF the requirements of the "Web
Content Accessibility Guidelines 1.0" [WCAG10."
> 21b) Harmonize the language of Guideline 12 Notes as follows:
>
> "For the purposes of this document, features that benefit or
> affect accessibility are:
>
> 1) The features of specifications (implemented to satisfy the
> requirements of this document) that are identified as
> accessibility features, and those that enable the author to
> satisfy the requirements of the "Web Content Accessibility
> Guidelines 1.0" [WCAG10], whatever the priority."
>
EH: Make similar edits.
> 2) The features of the user agent that satisfy the
> requirements of UAAG 1.0 and the requirements of operating
> environment accessibility guidelines."
>
> 19c) I'd like to factor 21b into one Note (e.g., 12.2) then
> cross-reference it from the other checkpoints in Guideline 12.
>
> =======================================================
> 22) Checkpoint 12.5: "All changes" is too broad
> =======================================================
>
> Tantek argued that a developer may not be able to document some
> changes (e.g., because the information is confidential or
> proprietary), would probably not want to document all of them
> (because they could very well be numerous), and might not be able
> to determine readily (especially for low-level bug fixes) which
> ones affect accessibility.
>
> --------
> Proposal
> --------
>
> 22a) Change "all changes" to "important changes". This
> allows some filtering, and probably requires no more
> interpretation than "all changes" (i.e., it is no more vague
> thatn 12.5 already is). This doesn't address the
> problem of confidential information, but I don't think we
> can do much about that. Instead, it allows developers to
> satisfy the checkpoint by providing a reasonable list of
> important changes.
EH: Sounds like a reasonable and necessary change.
>
> 22b) Make this checkpoint a Priority 3 checkpoint. [This part
> of the proposal can be considered separately.] As a result
> of issue 373 [7], we chose not to make this checkpoint a P1
> checkpoint (since the full documentation is available, so having
> the changes available separately is not a P1
> requirement). However, I am not convinced that having the list
> of changes available merits even priority 2.
EH: I don't have a strong feeling on this.
>
> [7]
> http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#373
>
> =======================================================
> 23) Is the glossary informative?
> =======================================================
>
> Tantek asked whether the glossary was informative. I don't think
> it is. While some terms are clearly informative (e.g., "assistive
> technology), others are clearly not just informative
> (e.g,. "recognize", "content", "animation"). In fact, most of the
> glossary entries probably include information that is important
> for conformance (and thus cannot be considered non-normative).
>
> The references section is split into normative and informative
> references (DOM is normative since it must be implemented for XML
> content).
>
> --------
> Proposal
> --------
>
> Add the following Note to the beginning of the glossary:
>
> "This is a normative glossary, although some of the terms (or
> parts of explanations of terms) do not affect conformance."
EH: Ok.
>
> I don't think it's worth trying to identify the normative and
> non-normative parts of the glossary. Or rather, it might be worth
> it, but I don't want to do it right now.
>
> =======================================================
> 24) Does "document source" include HTTP headers? What
> is the relationship between content negotiation and
> conditional content?
> =======================================================
>
> The definition of "document source" starts:
>
> "In this document, the term "document source" refers to the
> data that the user agent receives as the direct result of a
> request for a Web resource (e.g., as the result of an HTTP/1.1
> [RFC2616] "GET", or as the result of viewing a resource on the
> local file system)."
>
> According to this definition, HTTP headers are part of the
> document source. But are they part of content?
>
> The answer is no, not according to our document. We say that the
> document object is generally derived from the document source
> (and possibly the result of repair, etc.). The user agent is not
> required to transfer all of the document source to content (i.e.,
> the document object).
>
> We say that content is the document object. And that conditional
> content is content. Therefore, conditional content does not
> include Web resources in other formats (content negotiation)
> or languages (language negotiation) that the user agent could
> access but has not due to the user's configuration.
>
> --------
> Proposal
> --------
>
> No change to the document.
EH: Ok.
>
> --
> Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
> Tel: +1 831 457-2842
> Cell: +1 917 450-8783
>
Received on Thursday, 10 May 2001 10:09:50 UTC