WAI Page Authoring Guidelines Issues List for the Working Drafts (Pre-Rec)
Last revised: $Date: 2000/11/08 08:27:06 $
This page shows the history of issues the PA WG resolved prior to
the PA guidelines document going to last call.
Table of Contents of Issues
Closed issues
Issue raised by: Eric Hansen
and
Jon Gunderson, 17 March.
Issues
- First three guidelines not organized clearly.
- There are several axes to consider here, including:
- The format of the "primary" information: audio or visual
- The format of the alternative information: text, audio, or video.
- The purpose of the alternative information: text equivalent (function)
or description (appearance)
Resolution
From 23 March minutes: merge Guidelines, examine results. The
specifics are available in the minutes.
Issue raised by:
Greg Lowney - 8 Mar 1999
Issues
- In checkpoint (15.10 of 16 March version), it
reads "Use class="nav" to identify the group.".
This is a hack and should not be promoted.
Resolution
From 23 March minutes: move to Techniques document.
Issue raised by:
Greg Lowney - 8 Mar 1999
Issues
- See checkpoint (3.3 of 16 March version).
Resolution
From 23 March minutes: "where there is no user interaction to trigger them."
Issue raised by:
Chetz Colwell - 16 Mar 1999
Issues
- Checkpoint 11.3 says "Provide keyboard short-cuts to links". Does this
mean for all links? If there were many links on a page this would be
impossible.
Resolution
From 23 March minutes: add the word "important" to the checkpoint
so it talks about important links.
Issue raised by:
Jaap van Lelieveld - 15 Mar 1999
Issues
- Instability of the screen becuse of moving objects (already mentioned
but from a different view point).
- In many cases Javascript-based links behave different than
HTML links. How can this be avoided.
- Links sometimes have strange names: the names of the scripting
routines they belong to. How can this be avoided.
- Because of scripting requirements links show up in the tab
order that are no real links. They are only needed for
technical reasons. How can these "hidden links" be
avoided or how can they be recognized by the screen
reader (and rejected as irrelevant) or by the user?
Resolution
From 23 March minutes: This is more for the user agent group. Action
Al Gilman to send a summary of the discussion.
Issue raised by:
Jon Gunderson, 17 March.
Issues
- We have eliminated the notion of the "brief description"
(see 11 March minutes) and said in the techniques document
that 'title' should be used in accordance with the HTML 4.0
specification.
- Should we say explicitly how to use it for images? In
the guidelines or techniques doc as well?
Resolution
From 23 March minutes: No.
Issue raised by:
Jon Gunderson, 17 March.
Issues
- What should content developers say with the
attribute? Is the info meant for user agents?
Resolution
From 23 March minutes: Delete this.
Issue raised by:
Jon Gunderson, 17 March.
Issues
- Checkpoint 15.10 in 16 March draft;
Group related links, identify the group (for user agents), and, until
user agents do so, provide a way to bypass the group.
- Wants to be able to allow navigation within a group
of related links.
Resolution
From 23 March minutes: In light of definition of priorities, leave
as priority 3.
Issue raised by:
Phill Jenkins - 20 March.
Issues
Change:
8.3 For pages that use style sheets or presentation markup, ensure that the
content of each page is organized logically.
To:
8.3 Ensure that the content is organized properly [1], including content
that uses style sheets, presentation markup, applets, or programmatic
objects [2]. [Priority 1]
This makes it more likely that the content will be understood even when
styles are turned off, overridden by the user, or unsupported by the user
agent. Provide equivalent content and descriptions that are organized
properly [1] for applets and programmatic objects [2] so they will be
understood even when they are turned off, overridden by the user, or
unsupported by the user agents.
Techniques for checkpoint 8.3
Then:
- add a link to "Guideline 5. Use markup and style sheets properly."
- add a definition and a link to the definition of "programmatic
objects"
Resolution
From 23 March minutes: It's ok for checkpoints to not start with a
verb for "until" and conditional cases.
Issue raised by:
Wendy Chisholm - 22 March 1999.
Issues
I think the checkpoints for scripts ought to read like this:
- Ensure your page is usable without scripts. P1.
If you cannot make the page usable without scripts,
provide an equivalent mechanism to provide the
function of the script.
- Ensure that elements with scripting events are keyboard operable. P1
(i.e. directly accessible so maybe a P2 if #1 is satisfied).
- We probably don't need text equivalents for scripts
other than those that have some purely visual impact.
Resolution
From 23 March minutes:
- One P1 checkpoint will discuss pages working without scripts.
Text equivalent will be one technique for that.
- One P2 checkpoint about keyboard activation of event
handlers until UAs allow other means.
Issue raised by:
Warner ten Kate - 11 March 1999.
Issues
Possible to make priority 1 in light of use latest
W3C specs wording?
Resolution
From 23 March minutes: No change, based on definition of priorities.
Issue raised by:
Warner ten Kate - 11 March 1999 and follow-up Warner, 15 march
Issues
Should the checkpoint on ensuring all information
is available without color be modified to allow
purely decorative color and no backup mechanism?
Proposal
When text has a purely decorative value and conveys no information
other than the color itself, it is not necessary to provide that
information elsewhere
Resolution
From 23 March minutes: No, the checkpoint should not contain
this information.
Issue raised by:
Tim Berners-Lee - 14 March 1999
Issues
Using different markup to avoid word wrap when TABLE
is the correct choice is a mistake. What to say in
this checkpoint?
Resolution
From 23 March minutes: With "until user agents", this is ok.
Also, add a word not to discourage proper use of tables.
Issue raised by:
Japp van Lelieveld - 15 March 1999
Issues
It is mentioned here braille-displays do not have a "pointing
device". This is not true any more. Nearly ALL today's
brailledisplays include a pointing / clicking mechnism. The problem
though is "where to click" instead of "how to click".
Resolution
From 23 March minutes: Remove parenthetical comment.
Issue raised by:
Jon Gunderson - 16 March 1999
Issues
I think this checkpoint needs to be priority 1. If you use absolute units
in style sheet as soon as you increase font size you get alphabet soup. Or
if you leave it priority 2 could you add a reference in the techniques
document to have them check their page with style sheets turned off, to
make sure the page reads logically.
Resolution
From 23 March minutes:
Closed Issues
Issue raised by:
1998JulSep/0002
Resolved:
Issue
We have several guidelines that are associated with several different
techniques. Some of the techniques will work with current browsers, but are so
convoluted or not elegant that they should eventually become obsolete. However,
we can't recommend that the newer, more elegant strategies be used until they
are widely supported.
Working Draft Specifications
- By separating the techniques into their own document, we are able to
generalize the techniques.
- We also added language such as, "until browsers support" to
techniques that are more applicable in the future.
- @@ In the techniques document we will link to sites that track browser
support
Issue raised by:
1998JulSep/0001
Resolved:
Issues
In a number of places we say that you must do something if it is 'enough.'
For example, if tables are complex enough you must blah blah. or If images
present enough info you should use LONGDESC. What is the best way to help
authors determine which guidelines they need to follow and of those that they
are following, which techniques should they apply.
Working Draft Specifications
- The language for techniques and guidelines has been modified to be more
explicit.
- Tthe upcoming release of a checklist should further help people make
decisions.
Issue raised by:
Al
Gilman - 27 Aug 1998
Issue resolved: 14 Jan 1999
Issues
Have we appropriately conveyed what needs to be done for people with
cognitive disabilities? Have we sufficiently stated that graphics should not be
avoided but used with care? Do we need to mention the use of "easily
understandable" graphics; perhaps in "Good Design"?
Actions
- In the December 7, 1998 working group draft, several guidelines were
reworked such that there now exists a guideline related to comprehension (B.3)
and another related to navigation (B.2). However, is this enough? Are language
and other issues properly addressed (see the thread "Priority
for Techniques Dealing with Foreign Language Markup")?
- On December 9, Judy Brewer sent a
request for Cross
Disability Review to several organizations, including some that represent
people with cognitive disabilities.
Resolution
We seem to cover the issues in the guidelines, however,
the priority of those issues is a separate
item. Markup of foreign language is also a separate item.
Issue raised by:
1998JulSep/0097
&
1998OctDec/0033
29 Jul 1998 & 23 Oct 1998
Issue resolved: 14 Jan 1999
Issues
Definitions needed for tables: "well written,"
"complex," "simple"
Proposals
- To get around having to define "complex" tables
rewrite
the table guidelines as proposed by Charles McCathieNevile.
- Use classes to define table types (such as wai-column or wai-data)
as
suggested by Jon Gunderson.
- Definition of complex tables -
Daniel
Dardailler - 23 Oct 1998
Resolution and Actions
- A.8.2 and A.8.3 were promoted from Priority 2 to Priority 1.
- A.8.2 now says, " For data tables, identify headers for rows and
columns (e.g., the HTML TD and TH elements). [Priority 1]
- A.8.3 now says, "For data tables that have more than one row and/or
more than one column of header cells, use markup to associate data cells and
header cells (e.g., in HTML, THEAD, TFOOT, TBODY, COLGROUP, the
"axis", "scope", and "headers" attributes, etc.).
Issue raised by:
Daniel
Dardailler - 23 Nov 1998
Issue resolved: 14 Jan 1999
Issues
- Guidelines should emphasize Universal Design.
- Implies reworking content, particularly rationales, to broaden focus from
disability to universal design.
- Will sell better.
- Need to be careful that we dont weaken the use of guidelines by places
that want to legally require accessibility but cannot require general
usability.
Resolution
We won't mention "universal design" explicitly in the guidelines
but we will include universal design-type reasons as good ancillary reasons for
compliance. We have no mandate telling us to write these guidelines for
universal design, but it is good to point out. The introductory text to the
guidelines will clarify the relationship between device independence and
accessibility.
Issue raised by:
Gregg
Vanderheiden - 17 Nov 1998
Issue resolved:
Issues
- The guidelines themselves aren't assigned a priority based upon their
merit. They, in fact, inherit their priority as being whatever the highest
priority of the technique that is listed under them.
- The priorities between guidelines and techniques can be confusing.
- The majority of guidelines are P1, a handful are P2, and none are P3 (due
to the inheritence of priority from techniques).
- Some guidelines should probably be a P1, but because there are no P1
techniques they are a P2.
Proposals
- Remove priorities from the guidelines, leave on techniques.
- Implement "impact ratings" by disability group for each
technique.
Actions and Resolutions
- Priorities have been removed from the guidelines in the guidelines
document (but remain for techniques).
- Concensus reached on:
- Ratings only on checkpoints, not on guidelines.
- A single priority rating based on impact.
Issue raised by:
Gregg
Vanderheiden - 10 Nov 1998
Issue resolved:
Issue
In the current title ("WAI Page Author Guidelines") "Page
Author" is not appropriate since persons usually author more than a single
page. There is consensus that:
- The title should reflect that it addresses more than just a single page
in isolation.
- The phrase "Universal Design" should not be used in the title
since it carries so many negative connotations (so "Universal Design
Guidelines for WWW Documents" is out).
- We don't want to focus in on particular technologies (so "HTML and
CSS Accessible Design Guidelines" is out).
Proposals
- Web Author Guidelines
- Site Author Guidelines
- Web Content Accessible Guidelines.
- Web Site Accessibility Guidelines
- W3C Web Accessibility Initiative Author Guidelines (then make other
groups - W3C WAI User Agent Guidelines and W3C WAI Authoring Tools Guidelines)
- Guidelines for Accessible Web Sites
- Web Site Accessibility - WAI Guidelines for Authors
User Agent Accessibility - Guidelines for software developers.
Authoring Tool Accessibility - Guidelines for tool developers. (got at
least 4 votes and was the last suggestion of the most recent thread)
- W3C/WAI Web Site Accessibility Guidelines - for authors.
W3C/WAI User Agent Accessibility Guidelines - for software developers.
W3C/WAI Authoring Tool Accessibility Guidelines - for tool developers.
- The framework of the names for the WAI set of guidelines was determined
by the Coordnation Group. They chose, "W3C working group chosen phrase
Accessibility Guidelines." The group needs to determine whether they like
"site" or "content."
Actions
- After telecon discussion on 14 Jan 1999 the following names were sent to
the wai-gl list: W3C Web Site Accessibility Guidelines or W3C Web Content
Accessibility Guidelines.
- Several people responded favorably to "Web Accessibility
Guidelines" as
per
Al Gilman's discussion.
- The Coordination Group decided that the name would be "Web Content
Accessibility Guidelines."
Issue raised by:
Daniel
Dardailler - 6 Jan 1999
Issue resolved:
Issues
the priority of several checkpoints ought to be lowered from P1 to P2.
- A.5.2
- A.10.1
- A.10.2
- A.9.1
- A.9.2
- A.1.6
Proposals
- A.9.1 - See the next issue, "Legacy
solutions and priorities"
Actions
- A.5.2 - to become P2, unless any versions of UA can not override color.
- A.10.1 - keep as P1
- A.10.2 - include more accurate information (if available). keep P1.
- A.9.1 - keep P1
- A.9.2 - checkpoint to reflect more general idea, move HTML specifics to
techniques document, keep p1.
- A.1.6 - update checkpoint to read: ASCII art should either be replaced
with Image, Alt, longdesc, OR a description and mechanism to avoid it. maintain
priority 1.
Issue raised by:
Nir
Dagan - 12 Dec 1998
Issue resolved:
Issues
- What information should the guidelines cover in regards to HTTP
Content-Language header information?
- Do we need a section devoted to HTTP server guidelines that would discuss
not doing browser sniffing&discrimination, supporting language/content
negociation, etc.? If not, where does this issue fall?
- How many authors have control over the configuration of the server
serving their pages?
- How many authors are willing or able to modify these settings?
Proposals
- A separate W3C document: Webmaster guidelines.
- Integrate into current document.
Actions
As discussed in
the 21 Jan
1999 teleconference, proposed language will be incorporated into the
guidelines and techniques documents.
Issue raised by:
Nir
Dagan - 23 Nov 1998
Issue resolved: 28 Jan 1999
Issues
- Tips for style sheets are needed.
- Are these just good design or increased accessibility?
Proposals
see
Nir's
message (and the following threads) for proposed techniques and wording.
Actions
- Ths issues was discussed at
the 21
Jan 1999 teleconference.
- It was determined that nothing else needed to be added to the Guidelines
document, but that something may need to be added to the Techniques document.
Daniel is following up with the W3C CSS gurus for suggestions.
Issue raised by:
Charles
McCathieNevile - 6 Jan 1998
Issue resolved: 28 Jan 1999
Issues
- Some checkpoints should currently be P1 to work with older technologies
still widely used. However, as technology evolves, the priority of the
checkpoint will decrease.
Proposals
- Reinstate a time sensitive label of some sort.
- "beef up the current a.13 'use interim solutions...', separate it
from the general flow, and give it a slightly different priority structure -
one which recognises that the priorities may change. (for example A B C, where
A means 'currently used technologies cannot cope without this checkpoint', B
means 'currently used technologies can only barely cope without etc etc')"
Actions
The group recognizes that some priority 1 items will not be priority 1 in
the future as user agents incorporate needed mechanisms. Therefore, items
should be priority 1 if a well designed UA can not handle it (e.g.,
descriptions of images - author has to provide, the UA can't synthesize) and
priority 2 otherwise (e.g., frames are navigable by some UAs but not all).
Issue raised by:
Gregg Vanderheiden -
14 Jan 1999 (teleconference call) Raised again by
Jonathan
Chetwynd - 2 Mar 1999
Issue resolved: 19 Feb 1999, reconfirmed 11 Mar 1999
Issues
- We are concerned that there is not a P1 checkpoint specifically for
cognitive disability concerns but the group could not come up with any others
that didn't seem to already be covered (at their base level - they will be
expanded on in the techniques doc). During the teleconference we discussed
B.3.1 and B.3.2 as possible checkpoints to raise in priority.
- Checkpoint
B.3.1 is currently a Priority 2. Could it be raised to Priority 1?
("Use the simplest and most straightforward language that is possible for
the content of your site. [Priority 2] ")
- We will be requiring people to use "as simple as possible"
language.
- It is hard to determine if people follow. However, we don't rate
things based on how easy it is to comply with but on how necessary it is for
access.
- On some sites, simplifying the vocabulary means a loss of precision.
Will the wording of this guideline address this problem or will people just
complain that their sites don't lend themselves to simple language?
- This is similar to what the HTML 4 working group went through with
ABBR and ACRONYM. They aren't defined that differently in the dictionary,
people have different interpretations and UAs already had various
implementations. Therefore, they decided they didn't need to define the
difference between them nor outline how decide which to use; they left them
both in.
- With at least one of these as a Priority 1, we would show strong
support for cognitive disabilities.
- Checkpoint
B.3.2 (use of graphics where appropriate to facilitate comprehending) is
currently a Priority 3, but might be a Priority 2. ("Use icons or graphics
(with alternative text) where they facilitate comprehension of the page.
[Priority 3] ")
- Should not be a Priority 1 because it is sometimes harder to
interpret images rather than words.
- Increasing the priority to at least 2 might decrease the perception
that we say "images are bad, don't use them."
- We should also consider giving one or both a variable priority, along the
lines of, "If the information is important to understanding the page, make
it a P1 otherwise P2."
Proposals
- We should have a general staement in the introduction that says something
about important information/functionality, and 'presentational candy' - in the
latter case it is acceptable to let the content/function disappear so long as
it doesn't break the document.
- The only general page authoring mechanism is to ask the author to provide
redundent forms of information and hopefully the user agent will allow the user
to filter the representations that is most effective for themselves.
Resolutions and Actions
- B.3.1 is a p2, B.3.2 is P3.
- Style writing guidelines were added to techniques document.
- The rationale for B.3 was "beefed up."
- The checkpoint (B.3.1) was reworded.
- The priority for "Use icons or graphics (with a text
equivalent)" (now 16.2) was kept at P3.
Issue raised by:
Jon
Gunderson - 8 Dec 1998
Issue resolved: 18 Feb 1999
Issues
- Important for accessibility.
- Direction is needed for professors using math on the Web (30-40% of UIUC
campus using math on web pages). It needs to be visible (i.e., it's own
checkpoint).
- Too few solutions.
- It is covered in the guidelines already (use W3C technologies, provide
descriptions of important graphical information), but the examples don't
include.
Proposals
- Today use image with alt and a description, in the future use MathML.
Actions
As discussed in
the 21 Jan 1999
teleconference, proposed language will be sent to the list to include
server strategies in current checkpoints (actually
sent on 8 Feb).
Issue raised by:
Charles
McCathieNevile - 4 Dec 1998
Issue resolved: 11 Feb 1999
Issues
- The list of checkpoints "form a set of criteria which can be
satisfied to provide a rebuttal presumption that the guidelines have been
met."
Proposals
- "So the statement of conformance would say that a document or
resource must satisfy the guidelines to be accessible. Further, there are a
number of techniques which have been established, along with a statemnt of
their relative importance, as means to implement the guidelines in specific
circumstances. "
Actions
- Passed to Coordination Group. We are waiting to see how this issue is
handled in UA.
- Discussed and resolved on telecon then follow-up on list.
Read the proposal from the 11 Feb
telecon.
Issue raised by:
Charles
McCathieNevile - 22 Dec 1998
Issue resolved: 11 Feb 1999
Issues
Need to make A.12 more general.
Proposal
Ensure that features of the page can be activated in ways that are not
device specific.
Rationale: (obvious)
General: in general it is sufficient to ensure keyboard access, as most
sytems allow other devices to provide control as if it were done from the
keyboard.
Checkpoint: Use of mouse-specific triggers onMouseOver etc is not
accessible, and some alternative means of accessing the functionality is
required. Note: Hopefully this will be addressed in future versions of HTML and
User Agents. In particlar some mouse-based events such as onClick, as
interpreted by common browsers, could easily be replaced by non-device specific
events such as onActivate.
Resolutions and Actions
Added checkpoint to the device-independence guideline that says, "For
scripts, specify logical event handlers rather than device-dependent event
handlers. [Priority 2] For example, in HTML use "onfocus",
"onblur", and "onselect". "
Issue raised by: Nir Dagan - 6 Jan 1999
Issues
- Why is relative (with respect to containing element) better than absolute
(with respect to view port) positioning? I would replace the checkpoint with:
Don't use absolute font size. (in regards to "A.6.5 Use relative sizing
and positioning (e.g., percent values) rather than absolute (e.g., pixel or
point values). [Priority 2]" )
- Won't it make a page unreadable if the fonts are magnified?
Resolutions and Actions
Checkpoint says," Use relative rather than absolute units in markup
language attribute values and style sheet property values. [Priority 2] For
example, in CSS, use 'em' or percentages lengths rather than 'pt' or 'cm',
which are absolute units. " Absolute positioning is still a problem. Will
be discussed in Techniques doc.
Issue raised by:
Jason
White - 2 Mar 1999
Issue resolved: 11 Mar 1999
Issue
A checkpoint that requires authors to comply with document type definitions
as provided in W3C specifications, seems to have disappeared from the
guidelines. While guideline 13 refers to using W3C technologies according to
specification, it does not mention compliance with a valid DTD.
Resolutions and Actions
Add a Priority 2 checkpoint that says, "Create documents that validate
to published formal grammars (i.e., document type definitions or schemas) and
identify those grammars."
Issue raised by:
Warner
ten Kate - 11 Mar 1999
Issue resolved: 11 Mar 1999
Issue
- we need to explicitly say that use of H1 conveys structure
- we need to distinguish between improper nesting and skipping levels (one
more serious than other).
- No H3 before H2.
- H2 -> (H3) -> H4 -> H3 >
- the use of heading levels should reflect the structural organisation of
textual context. (ala Warner)
Resolutions and Actions
- New wording for checkpoint 5.1: Use header elements to convey logical
structure and use them according to specification.
- In techniques, tell readers:
- Don't use Hx for font effects
- Don't skip levels
- Order/nest appropriately.
- Include a technique with DIV/Hx to show how to control a whole
section with style sheets.
Issue raised by:
Eric
Hanson - 3 Mar 1999
Issue
- Is the correct way to denote the conformance level with {P1, P12, P123}
or {A, AA, AAA} or {CL-1, CL-2, CL-3} or other?
- The conformance statement should be reworded to contain more specific
information, some of which ought to appear in a detailed discussion in the
Techniques document.
Resolutions and Actions
- Issue 1 has been resolved
(see 11 March minutes)
in that the group reached consensus on using,
"A/Double-A/Triple-A"
- Still open as of 22 March teleconference.
See
proposal from Judy.
Issue raised by:
Greg
Lowney - 8 Mar 1999
Issue
Does the priority of "Use high color contrast" (4.2) decrease when
"Ensure that information is understandable without color" (4.1) is
done well?
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Greg
Lowney - 8 Mar 1999
Issue
- Marking up lists correctly is not a P2 but a P3 checkpoint.
- Discussion about the usefulness of lists as navigation aids (see
Jason White't message).
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Greg
Lowney - 8 Mar 1999
Issue
- Should be a higher priority to ensure that pages can be used when style
sheets are turned off Therefore if it's important that a paragraph be set off
(e.g. indented) I'd use BLOCKQUOTE instead of relying on style sheets. What
aids or other tools would be adversely affected in real life by this?
- If this element is used inappropriately, then a speaking browser, a
braille translator, etc., will treat the enclosed text as a quotation, thus
providing the reader with an inaccurate understanding of the document's
content. Also, the use of BLOCKQUOTE for purposes of indentation violates the
separation of content and presentation. (see
Jason White't message).
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Greg
Lowney - 8 Mar 1999
Issue
- When link text can't be reasonably worded so as to be understood out of
context, TITLE should be used to add longer names for the links that would
distinguish them from each other. This is a very powerful technique and of much
benefit to accessibilty aids and other tools (such as those that provide a list
of the links in a page).
- The "title" attribute in HTML is meant for advisory titles
(e.g., on a link, to describe the target). It should not be assigned the
exclusive role of providing a description of an image, script, etc.
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Greg
Lowney - 8 Mar 1999
Issue
Why is it a P1? Think it should be a P3. In many cases, using older, more
established recommendations are more beneficial.
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Greg
Lowney - 8 Mar 1999
Issue
Recommend demoting it to Pri 3, as it doesn't necessarily cause
accessibility problems. If the only problem is one of compatibility with screen
readers, then the fact that a good number of UA (like IE, using Active
Accessibility, or future UA which could put a default placeholder in as an
option) don't have that problem would seem to relegate it to lower priority.
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Greg
Lowney - 8 Mar 1999
Issue
Should be P3 since it improves usability not basic accesibility.
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Tim Berners-Lee (and others)
Issue
In relation to several of the recent discussions, such as accessibility of
lists and headers, there is a fine line between who has the primary
responsibility for providing access - the author or the user agent. For
example, Charles McCathieNevile gives an example of how to make a list
maximally accessible (see Charles' message from ....). He is adding information
to the list structure that could potentially be provided by the user agent in
the future. Do we drop these? Add an "until browsers..." clause?
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Misha
Wolf - 10 Mar 1999
Issue
I'm baffled by the title: "Supplement markup to aid interpretation of
text" In what sense do any of the recommendations under this guideline
supplement markup?
Resolutions and Actions
"Clarify natural language usage."
Resolved in 22
March teleconference.
Issue raised by:
Misha
Wolf - 10 Mar 1999
Issue
Do we freeze the references to point to the "current" version of
each document at the time of the publication of the guidelines, OR do we point
to *the latest* version of each document by pointing to a non-date specific
URI?
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Tim Berners-Lee (and others)
Request
Highlight link types (e.g., LINK rel="next") in
section on using metadata.
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Misha
Wolf - 10 Mar 1999
Issue
- Clarify rationale.
- Clarify checkpoint wording along the lines of
Al's
suggestion to make the checkpoint more general as well as moving some of
the info to the Techniques document.
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by:
Warner
ten Kate - 11 Mar 1999
Issue
- Are there other natural language issues that have not been covered?
- Are there other cases where natural language should be identified? (ala
Warner ten Kate's message on captioning language)?
Resolutions and Actions
Resolved in 22
March teleconference.
Issue raised by: Several people, including
Warner
ten Kate - 11 Mar 1999
Issue
I found the section indexing "A", "B", "C"
confusing. I would number the sections and call the first appendix
"A".
Resolutions and Actions
Appendixes will be A, B, C. Otherwise numbers will be used.
Resolved in 22
March teleconference.
Issue raised by: Ian
Issue
Many checkpoints have a higher priority if the information being presented
by the element in question is "important" i.e., necessary to
understand or use the page. However, the guidelines currently do not handle
this consistently.
Proposal
Proposed: Use the checkpoint 10.1 text as the model - "Priority 1 if
information or functionality is important and not presented elsewhere,
otherwise Priority 2.]
Note. This may not work in all cases, for example, when the
checkpoint only applies when the information is important. Thus,
without important, it becomes a "Priority 0" and the
split would be awkward.
Resolutions and Actions
Proposal dropped by Ian.
Resolved in 22
March teleconference.
Issue raised by:
Chetz
Colwell - 13 Mar 1999
Issue
Who is the intended audience for this document and how do we state that in
the intro?
Proposals: The intended audience could be indicated: not in a way which
excludes those with less knowledge, but indicates the expected level of
knowledge and experience. Also it could be acknowledged that authoring tools
may not yet support the implementation of some tags, and state that the WAI is
working on that.
Resolutions and Actions
Resolved: No statement will be added.
Resolved in 22
March teleconference.
Issue raised by:
Chetz
Colwell - 13 Mar 1999
Issue
- More information is needed about assistive technologies, how users
interact with them, what they can and cannot do, how users and ATs will
interact with new elements.
- Statistics on the percentage of the population who are disabled could be
included.
- It seems that more information of this type would help authors understand
the purpose of the Guidelines and the utility of the new elements.
Proposals
- Proposals: Include definitions, examples, and other information either
within the body of the Guidelines, or in the Definitions Appendix.
- Create a separate document and submit as a note to the W3C.
Resolutions and Actions
- Add definition of assistive technology.
- Otherwise other proposals out of scope.
Resolved in 22
March teleconference.
Issue raised by:
Chetz
Colwell - 13 Mar 1999 and
Tim Berners-Lee
Issue
- Chetz's test participants had difficulties with re-finding sections or
references to sections, including the ability to keep track of which document
was being viewed. When Participants followed a link from the Guidelines to the
Techniques they did not seem to be aware that they had moved into a different
document; the transition was almost too seamless. Participants were
observed to follow a link to the Techniques and then scroll up to try to return
to the link they had followed, as if they were still viewing the same document.
- Tim identified (more or less) four classes of links in the document: a)
Links to the techniques document b) Links to the glossary (e.g., for "best
efforts", "important", etc.) c) Cross references within the
Guidelines document d) Links to the references section. Each type of link
should be identifiable to the reader.
Proposals
- Could the section numbers indicate the current document, such as G1.1 or
T2.2?
- Is there a way in which the numbering could match across the documents,
for example, could G1.1 relate to T1.1? Unfortunately, since the Techniques
document and the Guidelines document are organized differently (Guidelines by
issue, Techniques by issues then HTML topics) i don't think we will be able to
synch them up as suggested.
- <link> Techniques for providing text alternatives for images.
- definition of important, <link> examples of long descriptions for
imagemaps, <link> further information on long descriptions, etc.
Resolutions and Actions
March
16 version of guidelines addresses these concerns (though with a
few leftover links to be fixed.
Issue raised by:
Chetz
Colwell - 13 Mar 1999
Issues
- New elements and attributes are not supported in all HTML4 references.
- Designers are unsure how future browsers will support new elements and
attributes and therefore may be reluctant to use.
Proposals
- Include additional information in the techniques document about how to
use the new elements and attributes.
- Discuss how future browser may implement the new language features.
- Link to the UA working group guideline discussions of how they would like
to see the new features implemented.
Resolutions and Actions
Aside from links to WAI Web site, considered out of scope.
Resolved in 22
March teleconference.
Issue raised by:
Chetz
Colwell - 16 Mar 1999
Issues
- Checkpoint 7.4 talks about
using markup to associate data cells and header cells.
However, UAs don't yet support this markup. What should
be done in the meantime? Should there be something
in the guidelines or rather techniques on this?
Proposals
Chetz writes:
I seem to
remember that there used to be a Technique of using P or BR in table
cells to to make tables easier (if not accessible) for screen readers.
Resolutions and Actions
Resolved: No change in guidelines since old legacy problem
only.
Resolved in 22
March teleconference.
Issue raised by:
Tomas Valusek - 18 Mar 1999
Issues
- In Guideline 4, there should be mentioned that both foreground and
background color of a text element, or none of them, should be
specified. If an author specifies only one of these colors, the other
color shoud be so close to author's one, that the textual information
is unreadable.
Resolutions and Actions
This is technique information.
Resolved in 22
March teleconference.