W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

RE: [TECHS] Techniques Issues for Guideline 1.3 - plain text version

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Wed, 4 May 2005 08:58:48 -0500
Message-ID: <6EED8F7006A883459D4818686BCE3B3B01248341@MAIL01.austin.utexas.edu>
To: <Becky_Gibson@notesdev.ibm.com>, "WCAG " <w3c-wai-gl@w3.org>

Becky wrote:
<blockquote>
3. Emphasis [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#em] Use
the 
strong and em elements, rather than b and i, to denote emphasis. 
Editorial Note: Link to General technique about semantic markup. 
Joe Clark had some comments about <b> and <i> being acceptable in
certain 
cases [
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0321.html]. 
Associated tests:  none
Note that this is the only HTML technique associated with L1 SC 2 (which

is reworded in Joe's proposal for 1.3 but this technique still applies).
<action> 1. determine if we want to include the subtleties of b and i in
this 
technique?  Is so, ask Joe Clark to draft a paragraph to include with
the 
technique.  Or, assume for the average developer, that strong and em are

the best choice and that people who use b and i are doing so for a 
particular reason (which they understand) so there is no need to make
the 
distinction in the technique.  In other words, leave this technique as
is 
and address the b and i subtleties in the tests.
</blockquote>

For what it's worth, my proposal for 3.1 includes a L3 success criterion
about providing a mechanism to identify main ideas and other important
content (I know, "main" and "important" are fuzzy).  I bring it up here
because it occurred to me that this might actually be the sort of thing
that <em> was designed for-- not as a substitute for <i>, but as a way
to mark substantial pieces of content that need to be emphasized.

John


"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Becky_Gibson@notesdev.ibm.com
Sent: Monday, May 02, 2005 3:18 pm
To: WCAG 
Subject: [TECHS] Techniques Issues for Guideline 1.3 - plain text
version



Sorry, my last post was a hybrid HTML/Plain text version this is the
plain 
text version. That's what I get for having mail clients on different 
machines with different settings!


This is a long document that addresses the issues with the techniques
that 
are associated with Guideline 1.3.  I have tried to propose actions,
where 
appropriate but since Guideline 1.3 is still open, there are still
issues 
with mapping of the techniques to the correct Success Criteria.   In the

interest of completing the techniques documents I have sometimes taken
the 
stance of removing a technique that currently does not have substantial 
code examples or requires significant, additional research to complete. 

Rather than separating all o fhe URIs to a long list at the end of the 
document, I have included the URIs in line surrounded by square
brackets. 
I know this makes it more difficult for screen reader users but I felt 
that list at the end would be too cumbersome to be useful.  If you would

like a document without the URIs in-line please let me know. In keeping 
with requests from the list this document is in plain text.

I have grouped the techniques with issues by technology and numbered
each 
technique.  Any editorial notes that were associated witha  particular 
technique have been copied into this document.   Any bugzilla issue 
numbers are also listed.  For HTML techniques, any associated test
numbers 
are included.  I have tried to propose some action for each technique
with 
issues.  The actions are surrounded with <action> and </action>.


Issues with HTML Techniques

General Issue.
Most of the techniques that relate to GL 1.3 have the following
editorial 
note, "Editorial Note: Link to General technique about semantic markup."
<action> Give someone an action to create the general technique on
semantic markup 
and link to it from the appropriate techniques.
</action>

Specific techniques:

1.  The address element [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#address]
There are several editorial notes for this technique. 
Editorial Note: Describe how to use address to indicate contact 
information on the Web page.
Editorial Note: Question whether there is a particular accessibility 
benefit to this. If not, we should remove.
Editorial Note: Link to General technique about semantic markup.
Associated tests:  none <action> Propose removing this technique unless
someone can provide an 
accessibility reason for including address.  If technique is removed
there 
is no need to link to general technique or need to describe how to use 
address to indicate contact information. 
</action>

2. Section headings [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#hx]Use
HTML 
header elements h1 through h6 to define the structure of the document. 
There are several editorial issues:
Editorial Note: Edit this section to clarify "semantic chunks," "other 
markup," "introducing sections," "navigating its headings," etc.
Editorial Note: There has been some discussion about requiring h1 to be 
the first header on a page. It seems undesirable to restrict the use of 
header elements so far but some people support strengthening the
semantics 
of headers.   See the thread at [
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/thread.html ]
Editorial Note: Link to General technique about semantic markup. 
Associated tests:  #37 - 40, 42-47. 
Bugzilla issue: 925, 1070
<action>
1. propose closing #925 and NOT require only one H1 per page and not 
require that it be the first element. The general feeling (but not 
complete agreement) on the thread discussing this seemed to be that WCAG

should not require only H1 per document nor should we force it to be the

first heading in a document.  Propose writing up a summary of this 
information and include in the technique.
2. The test files already incorporate the issues raised in 1070 about 
ordering.  Suggest incorporating ordering info into existing technique
and 
closing 1070.
2. open new bugzilla issue to address the wording issues. 
</action>

3. Emphasis [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#em] Use
the 
strong and em elements, rather than b and i, to denote emphasis. 
Editorial Note: Link to General technique about semantic markup. 
Joe Clark had some comments about <b> and <i> being acceptable in
certain 
cases [
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0321.html]. 
Associated tests:  none
Note that this is the only HTML technique associated with L1 SC 2 (which

is reworded in Joe's proposal for 1.3 but this technique still applies).
<action> 1. determine if we want to include the subtleties of b and i in
this 
technique?  Is so, ask Joe Clark to draft a paragraph to include with
the 
technique.  Or, assume for the average developer, that strong and em are

the best choice and that people who use b and i are doing so for a 
particular reason (which they understand) so there is no need to make
the 
distinction in the technique.  In other words, leave this technique as
is 
and address the b and i subtleties in the tests.
2. create the necessary test files
</action>

4. Short Quotations (future) [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#q]Use the
q 
element to mark up short in-line quotations. 
Editorial Note: Link to General technique about semantic markup. 
Associated tests: none
<action>
1. since this is marked as a future technique and there are no tests - 
remove this technique.  The alternative is to keep the technique and 
create test files.
</action>

5. In-line structural elements to identify citations, code fragments, 
deleted text, etc. [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#semanticm
arkup
] Use structural elements as needed. 
Editorial Note: How often are these elements used? Are they supported by

assistive technologies? The code element is used often in W3C documents,

what about elsewhere? Should we keep this section? Perhaps keep it but 
make it clear it is for completeness and information?
Editorial Note: This is about several elements so perhaps should be
split 
up. But it's really just a list of structural elements. Do we need that 
list in techniques? Can we point to some resource (e.g., HTML spec) in a

single technique and say "use structural elements per the HTML spec"? Or

do we have to list every possible structural element we want people to
use 
- including the obvious ones like p?
Editorial Note: Link to General technique about semantic markup.
Associated tests: none <action> Remove this technique as using proper
structure should be covered by the 
general technique on semantic markup.  The alternative is to rework the 
technique and create test files for it.
</action>

6. Ordered lists [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#ol]Format

ordered lists so their items can be followed logically. 
Editorial Note: As above, how well do current screen readers support 
nested lists? How well is the support for CSS control of list styles? 
Associated tests: #149 & 150  - but neither has content. <action> 1.
This technique needs further research and rework.  Determine AT and UA 
support for this technique.  The current example uses CSS to implement -

need an HTML example that better matches the technique.
2. create test files
</action>


7. Identifying groups of rows (optional) [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#datatable
s_rowgroup
]Use thead to group repeated table headers, tfoot for repeated table 
footers, and tbody for other groups of rows. 
Editorial Note: Describe the use and benefits of row structure elements.

Clearly explain when it is a good idea to use these. Use Joe's example
of 
tbody. 
Associated tests: none.
<action>
Since this technique needs work, is marked optional, and has no tests, 
suggest removing it from first version of the HTML techniques document.
</action>

8. Identifying groups of columns (optional) [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#datatable
s_colgroup
]Use the colgroup and col elements to group columns.
Editorial Note: Describe the use and benefits of column structure 
elements. Much of this may be theoretical.
Associated tests: none.
<action>
Since this technique needs work, is marked optional, and has no tests, 
suggest removing it from first version of the HTML techniques document.
</action>

9. Specifying the set of data cells for which each header cell provides 
header information [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#datatable
s_scope
]Use the scope attribute to specify the set of data cells for which each

header cell provides header information. 
Editorial Note: Need support information for scope, headers, and axis 
techniques. Provide information to help determine which technique
(scope, 
headers, or axis) to use. 
Associated tests: none
<action>
This technique needs significant work.  It needs a better description
and 
currently there is no code example.  Consider removing it or assign
action 
for someone to complete it and associated test files.
</action>

10. Associating header cells with data cells [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#datatable
s_headers
]Use the headers attribute on each data cell to associate a list of
header 
cells that provide header information. 
Associated tests: none
<action> There is no code example for this technique. Assign action item

to create code example and associated test files.
</action>

11. Categorizing data cells [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#datatable
s_axis
]Use the axis attribute to place a cell into a conceptual category. 
Editorial Note: Andrew Kirkpatrick asks what specific accessibility 
benefits axis brings. Although testing shows assistive technology
support 
for this, it is unclear how this brings equivalency to non-disabled 
people, since in fact people who are not using AT currently do not have 
access to the axis information. We need to know more about how axis is 
intended to be used in the general case, and how using it benefits 
accessibility. 
Associated tests: none
Bugzilla issue 653. Determine use of caption and summary on
table-by-table 
basis and don't discourage use of both 
<action>
Since there is some question about the usefulness of this test and it
has 
no code example nor test files, suggest removing from this version of
the 
HTML techniques.
</action>

12. Markup and style sheets rather than images: the example of math [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#markupnot
image
]Wherever possible, use markup rather than images to convey information.

Editorial Note: Does this section fit best here or with images or on its

own? Perhaps pull bit about ASCII art from images and combine with this 
into a separate section called "Markup and Style Sheets" ? or perhaps 
create a more general section in General Techniques that would discuss 
benefits of marking text as text rather than developing raster images. 
Associated Tests: 135
[http://www.w3.org/WAI/GL/WCAG20/tests/test135.html]
Bugzilla Issue #184
Discussed in this thread: 
[http://lists.w3.org/Archives/Public/w3c-wai-gl/2004OctDec/0372.html ].
<action> Technique contains too much specific information about MathML
and not 
enough HTML specific info. Simplest option would be to remove technique 
from this draft. Other option is to shorten the MathML info based on 
comments from Issue #184 and include a code example.  Are there other 
examples that might be more mainstream than MathML?
</action>

13. CSS styling [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#css-style
]
Use CSS, not HTML, to style documents 
Editorial Note: Link to General technique about semantic markup 
Associated tests: none
This technique is associated with GL 1.3 but there is no specific SC.
<action>Remove this technique from HTML techniques document - specific 
issues are covered in CSS techniques.  If keep this technique it needs 
significant work as there is little descriptive text, no example code,
and 
no tests.
</action>

Proposed HTML techniques based on current proposal for Guideline 1.3:

1  Technique for marking up plain text documents. 
In his proposal for Guideline 1.3 Joe Clark wrote
<Joe>
Level 1 success criteria

                 1. Structures within the document can be
                 programmatically determined.

This means use (X)HTML, basically. It could also mean tagged PDF. I 
have a technique in mind for plain-text documents that we could talk 
about later.
</Joe>
<action>Ask Joe to write up technique for plain text.
</action>

2. Do we need an HTML technique for L1 SC3 about color - there are 
currently none? 
Although this may be too generic to provide any specific HTML
techniques. 
It might be possible to provide one or more techniques that show how to 
meet L1 SC3. 
Possibly show a select for picking colors that uses a background color
and 
the color name for each option - although most people use color names 
already.  Perhaps we only CSS techniques for this? 

3. Perhaps a technique to address Issue #1244,  Image-based headings 
This also relates to GL 1.1 and text alternatives.  But, if people want
to 
use images for headings, might as will have a technique that shows 
wrapping in an appropriate header element. 

4. Bugzilla Issue #1199 - encourage use of select elements 
This entry suggest creating a technique to encourage use of select over 
radio or checkbox
<action>
Ask author for more justification.  If none received, close and do not 
create a new technique. 
</action>



Questions about classification of techniques:

1. Do the techniques about NOT using tables for layout fall under this 
guideline or are they best left under GL 4.1 L1 #1? 
Here is the link to the start of layout table techniques: 
[http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#layoutta
bles]
Hee are the bugzilla entries about layout tables: 248, 1117, 1189

2. Where does the technique about summarizing data tables belong - it is

currently not categorized?
7.2 Summarizing data tables (optional) 
[http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#datatabl
es_summary] 
Use the summary attribute to describe the purpose and structure of data 
tables. 
Editorial Note: There is still not consensus about the ideal use of 
summaries for tables. A discussion about summaries began but there is 
still need for more review and comments on this. See also Summaries of 
layout tables. 
Associated Tests: 111,112,113
<action>
Propose that someone review various posts on IG and WCAG and make
decision 
on use of summary.  Update technique, create a code example and properly

categorize.
</action>

End HTML Techniques Issues relating to GL 1.3

Begin CSS Techniques Issues relating to GL 1.3

General Issue - there are currently no test files for any of the CSS 
techniques. 
Many of the CSS Techniques are just mapped to GL 1.3 with no SC
specified 
and thus need a specific mapping. Many of these mapped only to GL 1.3
are 
"best practices" and show correct usage of CSS.  We may want to remove 
some of these or map them to Joe's proposed L2 SC 1: "Only markup 
languages and technologies that enable separation of structure, 
presentation, and behavior are used."


1. Using em or percent for properties that need to change [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#units-that
-change
]
Editorial Note: Currently this is mapped to the guidelines for
'separating 
content from structure' and 'technology support,' however there was 
discussion at the 23 June 2004 techniques teleconference about a new 
guideline/success criteria about "transform gracefully." Issue 827 
Editorial Note: Tim Boland created a list of all CSS 2.1 properties that

support length units (of both relative and absolute values). Should we 
test all to determine accessibility issues related to use of px, %, and
em 
for each property? Issue 728. Is it ok to have fixed width layout 
specified in pixels and text specified in ems? Issue 1013. 
Bugzilla Issues: 728, 827, 1012, 1013
Issue 827 actually proposes a new success criteria - this should be
taken 
up in our general discussions about GL 1.3.
<action>
Assign someone to research issues and complete this technique. </action>

2. Using px  for properties that do not need to be changed [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#units-for-
static
]
Editorial Note: Tim Boland created a list of all CSS 2.1 properties that

support length units (of both relative and absolute values). Should we 
test all to determine accessibility issues related to use of px, %, and
em 
for each property? Issue 728. Is it ok to have fixed width layout 
specified in pixels and text specified in ems? Issue 1013. Also, Issue 
1020. 
Editorial Note: Currently this is mapped to separating content from 
structure and technology support, however there was discussion at the 23

June 2004 techniques teleconference about a new guideline/success
criteria 
about "transform gracefully." Issue 827 
Editorial Note: Add another example to show width and height of images? 
Bugzilla Issues: 728, 827, 1013
<action>
Assign someone to research issues and complete this technique and the em

or percent technique.  Need GL 1.3 completed before can determine the 
exact SC mapping.
</action>

3. Selecting individual characters or lines [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#char-selec
tion
]Use :first-letter, :first-line, or span to select individual characters

or lines. 
Bugzilla issues: 735
<action>
This technique is not mapped to a specific SC - need GL 1.3 completed by

working group before can determine the exact SC mapping. 
There has been discussion on the list about the appropriateness of the
two 
examples (one using the span element and another using :firstletter.
Need 
to assign someone the action update the technique with the UA support 
issue for :firstletter and pros/cons of the suggested technique.
</action>

4.  * Media types [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#media-type
s-tech
]Optimize presentation for a variety of devices by providing 
media-specific style sheets 
Editorial Note: Wording needs work 
Bugzilla issue: 1261
<action>
Assign SC mapping:  This technique is associated with GL 1.3 but there
is 
no specific SC mapping.  In Joe's current proposal I think it would map
to 
L1 SC 4. 
complete the technique: Create examples and update wording </action>

5. Creating borders [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#borders]Us
e 
style sheets to create borders around groups of content. 
Editorial Note: This technique does not clearly map to any existing 
Success Criterion. 
Bugzilla Issue: 1263 - please add rationale for using borders and
perhaps 
refer to HTML fieldset technique.
I'm not sure that adding a border around items qualifies as structure as

referred to in GL 1.3.  But, borders can be very effective to highlight 
something without the use of color (although outline would be better
than 
this but is not widely supported).  If we update the technique to deal 
with color separation ( draw a border around the error text in addition
to 
changing its color) it would map to Joe's proposed L1 SC 3.  This 
technique could also map to 2.4 but I can't find a specific SC there, 
either. 
<action>
Reach agreement on whether borders are considered structure as intended
by 
GL 1.3 and map as appropriate, map to another GL  or remove the
technique. 
 
</action>

6. Margins [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#margins]Us
e 
'margin', 'margin-top', 'margin-right', 'margin-bottom', 'margin-left'
to 
create space on four sides of an element's content. 
Editorial Note: This technique does not clearly map to any existing 
Success Criterion. 
Bugzilla issues: 1263 - questions techniques recommendation not to use 
&nbsp; - needs clarification
This has the same issue as the technique about borders - it does not map

to a specific SC.
<action>
Using margins is correct usage of CSS for layout - is it worthy of a 
separate technique? Suggest removing or rewriting to include an example 
with specific accessibility benefits.  Perhaps the issue of not using 
&nbsp; can be expanded to explain why &nbsp; to create margins is bad
for 
accessibility - then the example of using CSS margins makes sense.
</action>

7. Creating layout, positioning, layering, and alignment [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#layout]Use

'text-indent', 'text-align', 'word-spacing', 'font-stretch' to control 
spacing. Use 'text-align: center' instead of the deprecated html:center 
element. 
Editorial Note: Add 'clear' to the list? 
Bugzilla Issues: 1264, 308 (absolute positioning - although I believe
308 
maps better to CSS tech 13.1 Absolute positioning and structural markup.
<action> Map Issue 308 to CSS tech 13.1. Specify why this helps
accessibility?  Create example code (issue 1264 
asks for example of text-indent and suggests relating to misuse of HTML 
blockquote).
Create a general technique about using markup to layout and positioning 
rather than space character? Several CSS techniques would link to this 
general technique.
</action>

8. Positioning (float, position) [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#float]Use 
'float', 'position', 'top', 'right', 'bottom', 'left' to control
position. 

This is another technique that is mapped to GL 1.3 but no specific SC. 
<action>
Map to a specific SC ( probably L1 SC1 if you can consider these as 
"structural" otherwise maps to Joe' proposed L2 SC1.
Needs an example.
Link to Joe's alistapart article about zoom layouts?
</action>

9. Providing additional structural information [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#generated-
content-clues
]Use :before and :after to provide additional structural information 
Editorial Note: Text generated by style sheets is not part of the
document 
source and may not be available to assistive technologies that access 
content through the Document Object Model Level 1. 
Editorial Note: Find real-world example, such as a legal document, where

this is actually used or would be beneficial 
Bugzilla Issues:  253 - generated content 
This is another technique that is just mapped to GL 1.3 with no specific

SC. 
<action>
Remove reference to closed issue 191 from technique.
Determine if maps to specific SC - are  :before and :after considered 
structural elements?  May map to Joe's proposed L2 SC 1. 
Update technique to contain support info for :before and :after.
</action>

10. * Specifying colors [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#css-colors
] 
Use 'color,' 'background-color,' 'border-color,' 'outline-color,' and 
dynamic pseudo-classes to specify colors 
<action>This technique is currently mapped to L1 SC2 about emphasis.
Joe's 
proposal rewrites this to refer to semantics.  Since color is not 
considered semantic information it needs another mapping (perhaps Joe's 
proposed L2 SC 1) or should be removed. 
</action>

11. Specifying color values by hex value or color name (optional) [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#color-as-h
ex
]For best user agent support use a numerical hex value to specify
colors. 
<action>
Map to a specific SC - same issues as above - color is not semantic info

so remove or determine correct mapping. Does provide useful AT
information 
but not necessarily req. to claim WCAG conformance. 
</action>


12. Specifying fallback fonts [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#fallback-f
ont
]Always specify a fallback font. 
Editorial Note: What is the accessibility issue?
Editorial Note: JIS-related issue with selecting readable fonts. Issue
892 

Bugzilla issues: 
<action>
Determine accessibility reasons for specifying fallback fonts or remove.

Determine SC mapping - Joe's proposed L2 SC1?
</action>

13. Specifying font characteristics [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#css-fonts-
over-deprecated
]Use font-family, font-size, font-size-adjust, font-stretch, font-style,

font-variant, and font-weight to control font characteristics. 
Issues: currently mapped to L1 SC2 (emphasis) and L1 SC 3 (color).  I 
would argue that this does not map to L1 SC3 about color. 
<action>
Determine correct mapping - Joe discusses this issue in his proposal for

L1 SC4. But I am still unclear how backup font types solves an 
accessibility issue - it seems like more of a usability issue to me?
</action>

14. Creating stylized text with CSS rather than using raster images [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#text-as-te
xt
]Use style sheets to style text rather than creating images of text. 
Editorial Note: Related to Issue 827 and Issue 556 
Issues:  Currently mapped to all three current L1 SC - I don't think
that 
1.3 is relevant here (except perhaps Joe's proposed L2 SC1). <action>
Change mapping to GL 1.4 L1 SC1. 
</action>

15. Make raster image text accessible with CSS [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#raster-tex
t]
Make images of text accessible using background and positioning
Editorial 
Note: Related to Issue 827 and Issue 556 
Same issues and action as previous technique on raster images.

16. * Indenting text [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#text-inden
tation
]Use text-indent to indent text. 
Editorial Note: There is an "and" relationship between this and using 
structural elements (e.g., in HTML, use the header element and then
style 
with css) 
Bugzilla issues:1264 - provide example
Issues: Currently mapped to all three current L1 SC - I don't think that

1.3 is relevant here (except perhaps Joe's proposed L2 SC1). <action> I
don't see a SC mapping to any GL - need to find one or remove. If keep -
need to create code example. </action>

17. Changing case [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#text-trans
form-caset
]Use 'text-transform' to change case 
Bugzilla Issues: 1265 - what is accessibility issue with text-transform?
Issues: currently mapped to L1 SC2 (emphasis) which Joe's proposal 
rewrites to specify semantics. 
<action>
I think capitalized text is presentational rather than supplying 
semantics. Also, how does text-transform affect accessibility?  Consider

removing this technique. 
</action>

18.  Outlining content [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#outlines]U
se 
style sheets to outline groups of content. 
Issues.  Technique is mapped only to GL 1.3 and no specific SC.  Same 
issues as raised above for border technique (#5 above). <action> I don't
think outlines around elements can be considered  structural as 
intended by GL 1.3.  So, map to another GL or remove the technique. 
</action>

19. Absolute positioning based on structural markup [
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#absolute-p
ositioning
]Use structural markup and document order to design content that makes 
sense when CSS is not applied 
Editorial Note: "and" relationship with use of structural elements 
Issues:  Technique is not mapped to specific SC - not sure if it belongs

under 1.3.  Perhaps GL 2.4 L3 SC 1 instead?
<action>
 Technique has good information that is worth keeping.  Determine best
GL 
and SC mapping. 
</action.


Proposed CSS techniques.

1. Show how to use borders and outlines to highlight important
information 
without the use of color. This might need to be combined with JavaScript
- 
for example to show focus.  Map to GL 1.3 L1 SC 3 which there is
currently 
no CSS technique to support.

End CSS Techniques Issues relating to GL 1.3

Begin JavaScript Techniques Issues relating to GL 1.3

There are currently no JavaScript techniques mapped to GL 1.3.  It might

be possible to map some to Joe's proposed L1 SC 4.

I proposed some possible scripting techniques to the list 
[http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0249.html]. 

1. For L1 SC 2 I propose  John's idea of using Script to emphasize a set

of words in the document In this case I believe the emphasis could
convey 
semantic information about the data - perhaps they are all newly 
introduced or defined terms. 

2. For L1 SC 3 (color) I propose a combination of CSS borders and
outlines 
to highlight information that is also presented in color.  The example
of 
marking up table rows with a specific color and border when the user 
mouses over is one example.  This can potentially all be done in CSS for

UA's that properly support :hover and focus or JavaScript can be used to

change the className.   Another example would be to use color and 
border/outline to programmatically set focus ( although this is a more 
advanced technique as it requires IE 5 or better, Firefox 1.1 or Mozilla

1.8).

3. For Joe's proposed L1 SC 4 he suggested an example using generic 
handlers in JavaScript. 

4. Still need an example for L1 SC1.  One example might be to use the 
structure within a document to generate an alternative format for the 
document or parts of the document  For example to display all <divs> or 
spans marked with a particular id into a new window.  I'm not sure how 
that helps accessibility, though??? It really is just a contrived
example 
that shows the importance of using proper structural markup in a
document. 


End JavaScript Techniques Issues relating to GL 1.3



Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com
Received on Wednesday, 4 May 2005 13:59:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:37 UTC