Prepared for Team B teleconference 22 Aug 06 by Bruce Bailey.
Synopsis. Paraphrasing. Opinion. Comments.
There are 9 specifically identified issues, 26 general hits. Of the nine, 6 have been assigned to Team A, 2 to Team B, and 1 to the Editors.
Seven of eight are a request for user-controlled re-sizing (equivalent for WCAG 1.0 P2 checkpoint 3.4). One adds font choice and color to this. I have not considered the other 25.
Key concepts: user control, avoiding horizontal scrolling, Liquid layout.
No previously identified issues have changed since earlier report. This update adds issue (1253) and improves formatting and wording of conclusions.
No equivalent for WCAG 1.0 Priority 2 Checkpoint to “Use relative rather than absolute units in markup language attribute values and style sheet property values.”
Add guideline to use scaleable fonts and layout.
Suggestion variously attribute missing SC to GL 1.3, 1.4, and 4.1. One suggestion for new Guideline 1.5. Variously recommended at Level 1 or Level 2, but mostly 2. Some specific SC were included.
Commenters noted problem with previous 3.4 wording since “pixel” is a relative unit, but it is not user-scaleable.
One commenter noted that long blocks of text that are italicised or use center or even full justification can be hard to read for people with cognitive and reading problems.
This is UA issue.
Advisory technique to GL 1.3.
Advisory technique to GL1.4.
This analysis was much simpler than I expected since the comments are uniformly one sided! There were relatively few comments on this subject, but my intuition that these few are representative of much broader sentiment.
In my opinion, this is a serious omission. On the other hand, the absence of just such a requirement from the 508 standards has been unfortunate, but we have been living with it.
These issues effect everyone, but they are dispropitonatly barriers to people with low vision or specific learning disabilities
Just having an advisory technique does not seem sufficient.
Reliance on addressing the matter in UAAG does not seem sufficient. We have other SC that could also be mitigated by UA features, so it seems inconsistant to defer this important behavior to UA.
Gian Sampson-Wild has volunteered to draft SC. I bet she would be glad to author failure and success techniques as well.
Keyword seems misnamed, but let us stick with it. I was expecting character sets and such to confound this analysis.
If we don’t add SC, we should mindfully explain the rational for the deliberate omission.
Sorted by length, shorter first. New issue 1253 at end.
Sort Terms: FONT
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: mapping (Checkpoint
3.4)
Comment:
Relative vs absolute units: There should be a WCAG2 equivalent at Level 1 for
this WCAG1 checkpoint. The ability to change the text size in a page is very
important to people with vision impairments. The ability to resize tables according
to the size of the screen is very important to people using PDAs
Proposed Change:
Create a new SC outlawing absolute units (I am happy to write this)
Status: open
Working Group Notes: [TEAMA] [HOLD]
Resolution Working Notes - Unapproved:
Related Issues:
Assigned To: Nobody
Last Edited: 20060711215952
Sort Terms: FONT
Document: WCAG 2.0 Guidelines
Submitter: Henny Swan <henny.swan@rnib.org.uk>
Affiliation: Royal National Institute of the
Blind
Comment Type: general comment
Location:
Comment:
WCAG1, 3.4 (use relative fonts) not in WCAG 2. Unsure why this is.
Status: open
Working Group Notes: [EDITORZ] [HOLD]
Group agreed with this but send to HOLD to be considered with other comments.
Resolution Working Notes - Unapproved:
{QUESTION - ANSWERED}
Since fonts are a suggestion to the user agent and can be overridden there,
this issue is considered a user agent issue. An advisory technique, however,
is provided under guideline 1.4.
Related Issues:
Assigned To: Nobody
Last Edited: 20060721191805
Sort Terms: font
Document: WCAG 2.0 Guidelines
Submitter: M.F. Laughton <adio@crc.ca>
Affiliation: Government of Canada
Comment Type: substantive
Location:
Comment:
Principle 1: Content must be perceivable.
There is nothing in the current edition of WCAG to ensure Color requirements
/ User Choices of color/presentation/font needs are respected or requirements
in the new WCAG. A low vision user doesn't want a text equivalent, they want
something in a presentation they can read. Ie: 18 point font or black background
and white text.
Proposed Change:
There should be explicit guidance relating to color/presentation/font usage,
as at least a level 2 success criterion.
Status: open
Working Group Notes: [TEAMA] [HOLD]
Resolution Working Notes - Unapproved:
Related Issues:
Assigned To: Nobody
Last Edited: 20060705185700
Sort Terms: font
Document: Understanding WCAG 2.0
Submitter: Sean Curran <sean@srcurran.com>
Comment Type: general comment
Location: meaning
(Intent)
Comment:
Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):
I would add another section to 3.1 that alows users to increase or decrease
the text size through the browser or the website. Or the text will work with
multiple default text sizes. I think this is a bigger deal than screen readers
and zooming in. Most 50 people have bad eyesight and don\'t know how to use
windows zoom, but can be taught the make text bigger trick and have it as a
large size by default. This breaks some websites and makes the content un-usable.
Proposed Change:
Add a section under 3.1 that allows users to increase the text size a reasonable
amount and still have the website readable/usable/etc.
Status: open
Working Group Notes: [TEAMB][HOLD]
Resolution Working Notes - Unapproved:
Related Issues:
Assigned To: Nobody
Last Edited: 20060728183934
Sort Terms: FONT -- Relative Positioning
Document: WCAG 2.0 Guidelines
Submitter: Greg Gay <g.gay@utoronto.ca>
Affiliation: ATRC UofT
Comment Type: general comment
Location: ensure-compat-rsv
Comment:
Comment (Including rationale for any proposed change):
There is currently no item number relevant to this comment. Technique G96 seems
to be the only place within the WCAG 2.0 documents that mentions anything about
"relative positioning", or more specifically use of relative measures. Using
relative measures is particularly important for low vision users who use a browser
function to blow up the text size. It is also important for those using small
screens like PDAs.
Proposed Change:
This requirement seems to fit best under WCAG principle 4, regarding robust.
Perhaps a new guideline 4.1.3, at level 2. something like "Ensure that content
can be resized without losing its symmetry" Then in the techniques describing
the use of relative measures for sizing block level items, text, images, etc.
Status: open
Working Group Notes: [TEAMA] [HOLD]
Submitted from Team A 5/23/06
-----------------------------
1) @@ add the following advisory technique
"Using relative positioning." to guideline 1.3
2) @@ check with Ben to incorporate the C6 idea.
2) close item with
{Partial Accept}
"An advisory technique "Using relative positioning." has been added to guideline
1.3 to explain that allowing pages to maintain relative layout as fonts are
increased is of value to those with low vision that must scale fonts but do
not want the page to increase in width beyond the width of the screen."
---------
Surveyed and discussed 5/25/06 and put on HOLD
@@ ACTION: Gregg check with Ben to incorporate C6 idea for LC-469 [recorded
in http://www.w3.org/2006/05/25-wai-wcag-minutes.html#action01]
resolution: put LC-469 put on hold because more comments will likely come in.
Resolution Working Notes - Unapproved:
Related Issues:
564
Assigned To: Ben Caldwell
Last Edited: 20060718220646
Sort Terms: FONT
Document: WCAG 2.0 Guidelines
Submitter: Alastair Campbell <ac@alastairc.ac>
Affiliation: Nomensa ltd
Comment Type: substantive
Location:
Comment:
W2
1.5 (missing)
Intent,
Description,
Examples
I cannot find anything on relative sizing of fonts or layout, at all. (Also
noted in other comments.) I believe these are important aspects for accessible
computers in general as well as the Internet, for anyone with a mild to moderate
visual impairment.
* The most common user agent Internet Explorer (installed on many corporate
networks) does not allow the resizing of pixel sized fonts. Nor does the version
7(b3) update. (It does include 'zoom', but this causes horizontal scrolling
on any currently accessible site).
* Proper 'zooming' is not generally available yet (although some are working
on it.)
* Fixed width/height layouts suffer from a similar problem, partly because they
often do not react well to increases in font size. There are some basic layout
guidelines for HTML/CSS websites.
* It is applicable to all screen technologies. For example, Flash scales well,
but is often trapped in a fixed size window. Acrobat has re-flow & scaling.
Other new technologies should be required to scale well.
Relative fonts or layout may be covered in the techniques (although not when
I last searched), but I believe it should be part of the normative document
(level 2 success criteria).
Proposed Change:
Include a revised version of WCAG 1.0's checkpoint 3.4, example included below.
The font aspects could be added to 1.3, but it does not seem a natural fit.
Guideline 1.5 Use scalable fonts and layout
Level 1 Success Criteria for Guideline 1.5
(No level 1 success criteria for this guideline.)
Level 2 Success Criteria for Guideline 1.5
1.5.1 text sizing should be specified in a unit that is user re-sizable. The
interface should be perceivable and operable with text increased to a 200% size.
1.5.2 the layout of the page should allow for a variety of screen resolutions
and sizes by using relative units for the primary layout areas, such as overall
layout, and content area.
-------------------------------
Somewhat short, rough and ready, but I can expand on this if the concept is
agreeable. This article on basic layout guidelines (http://alastairc.ac/2006/05/accessible-layouts/)
could provide inspiration for the CSS techniques.
Status: open
Working Group Notes: [TEAMA] [HOLD]
Comment submitted 19 July 2006 (late)
Resolution Working Notes - Unapproved:
Related Issues:
Assigned To: Nobody
Last Edited: 20060727054304
Sort Terms: FONT
Document: WCAG 2.0 Guidelines
Submitter: Felix Miata <mrmazda@ij.net>
Affiliation: NA
Comment Type: substantive
Location:
Comment:
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
Guideline 1.4 is the only part of the whole document I was able to find that
addresses any component of the most basic element of accessibility to any non-blind
user attempting access entirely visually: legibility. Thus legibility coverage
appears to be inadequate, making the entire document inadequate.
If text content cannot be read at or all without pain, it is functionally inaccessible.
Nothing else matters when the content cannot be read. Other very important criteria
factor heavily in determining basic legibility in addition to the guideline
1.4 coverage:
1-font size
2-font family
Reduction of font size from the user preferred size, and substitution of an
author chosen font family for a user preferred font family, both cause a reduction
in legibility, and thus a reduction in accessibility.
The primary message from http://www.w3.org/QA/Tips/font-size
is hereby incorporated by reference, and should be a part of the guideline.
Additionally, please digest http://mrmazda.no-ip.com/auth/accessibility.html
for more detail and background on legibility as relates to accessibility.
Proposed Change:
Legibility is so fundamental a component of accessibility that it demands its
own subpart, with the current 1.4 a component thereof. The guideline in addition
to the current 1.4 should spell out:
1-Avoid font size reduction from the user preference for primary (e.g. centrally
located paragraph text) content. Never size text in px or any absolute unit.
2-Minimize font size reduction from the user preference for secondary content.
3-Use utmost care, preferably avoid entirely, substituting any font family for
the user\'s preferred font family for primary content. Font family substitution
should be limited to branding and secondary content.
4-Only users are in position to suitably determine the font size and font family
required to provide adequate legibility.
5-Not all users are empowered to compensate, either at all or to sufficient
degree, when authors deviate from these guidelines. (e.g., users of computers
situated in public libraries or kiosks)
Status: open
Working Group Notes: [TEAMA] [HOLD]
Discussed 06 July 2006
resolution: put LC-659 on hold to be addressed with other font legibility issues
http://www.w3.org/2006/07/06-wai-wcag-minutes.html
Resolution Working Notes - Unapproved:
@@ ACTION ITEMS
Add the following two techniques to Gl 1.4 or 3.1
1 - Avoiding font size reduction from browser default or user setting.
2 - Avoiding sizing text in px or any absolute unit.
- Using readable fonts. {already there now}
@@ Include in the intent section for these techniques the following rationale's
- Only users are in position to suitably determine the font size and font family
required to provide adequate legibility.
- Not all users are able to compensate, either at all or to sufficient degree,
when authors deviate from these guidelines. (e.g., users of computers situated
in public libraries or kiosks)
RESPOND WITH :
"Font and font size are controlled by the User Agent. Authors can suggest fonts
and font sizes but the user agent can always override them. That being said,
the working group does believe that it is good practice to use legible fonts
and sizes. The group has therefore added advisory techniques as follows to GL
1.4 (or 3.1 depending on final organization).
1 - Avoiding font size reduction from browser default or user setting.
2 - Avoiding sizing text in px or any absolute unit.
- Using readable fonts. {already there now}
We will include in the intent section for these techniques the following rationale:
- Only users are in position to suitably determine the font size and font family
required to provide adequate legibility.
- Not all users are able to compensate, either at all or to sufficient degree,
when authors deviate from these guidelines. (e.g., users of computers situated
in public libraries or kiosks) "
Related Issues:
Assigned To: Nobody
Last Edited: 20060706204841
Sort Terms: FONT
Document: Techniques Document
Submitter: Marco Bertoni <mbertoni@webaccessibile.org>
Comment Type: substantive
Location:
(clarifications about the terms "relative", "absolute" and "relative
positioning")
Comment:
I think that we need some clarifications about the terms "relative", "absolute"
and "relative positioning", expecially when they are used regarding both font
sizing units and CSS positioning rules.
In the "Comparison of WCAG 1.0 checkpoints to WCAG 2.0" [1] appendix we can
read:
In General (Priority 2):
3.4: Use relative rather than absolute units in markup language attribute values
and style sheet property values.
that is is related to:
WCAG 2.0 Success Criteria:
This maps to an advisory technique (Using readable fonts) for Guideline 1.4.
Guideline 1.4 refer to visual and audio contrast [2] and I've not yet found,
even in the "Techniques for WCAG 2.0", the advisory technique mentioned (Using
readable fonts).
Even in the "CSS Techniques for WCAG 2.0" draft [2] - in which is correctly
introduced the idea of "Using em or percent for properties that need to change"
instead of "Use relative rather than absolute units..." - the corresponding
guideline mentioned is "1.3" ...that refer to the separation of structure and
presentation.
However, as Gregg Vanderheiden told: "Most advisory techniques have not been
written yet".
Having said that, I must point up that using terms like "relative units", "absolute
units" or "relative positioning" maybe somehow confusing.
I'll start from the following assumptions:
1) The general accessibility principle in question is that users (expecially
partially sighted people) must be able to enlarge fonts using their visual UA
tools.
2) Microsoft Internet Explorer 6 for Windows - and all the previous versions
- is not able to enlarge text if it is sized in pixels. But pixels are "relative"
lenght units (they are relative to the viewing device resolution) [4].
3) On the other hand there are some CSS absolute-size values that IE/WIN can
perfectly enlarge: the absolute-size keywords (x-small, small, medium etc.)
[5].
So, it is really confusing to advise CSS designers that they should use relative
length units to size fonts.
CSS Techniques correctly tell us to "Use "em" or % for properties that need
to change". But we should make another stride to avoid to mention a specific
unit identifier: e.g. here in Italy, in our recent accessibility law [6], we
have introduced a requirement (Requirement 12) that says: "The presentation
and textual content of a page must be able to be adapted to the dimensions of
the browser window used by the user, without superimposing objects present or
loss of information such as to render the content incomprehensible, including
in the case of resizing, enlargement or reduction of the display area or characters
in relation to the predefined values of these parameters.". In other words,
with this approach we say that the designer must size characters with a unit
of his choice that guarantees the enlargement of text in every UA. This is expecially
useful to ensure forward and backward compatibility. We cannot forget that,
at the time of this writing, IE 6 cover almost all the market.
Cynthia Shelly suggested the term "scalable" to describe this text resizing
function.
Summarizing, there are relative and absolute CSS units that are scalable (also
in IE6/WIN):
1) for fonts: em, percentages and absolute-keywords (e.g. medium, small, x-small
etc.)
2) for containers: percentages and em.
But we have to think about the near future when IE/WIN will be able to make
pixels scalable. So we definitively should talk about *functions* rather than
units, and I agree with Cynthia that "scalable" is the right term to use.
Therefore I suggest to tell designers something like "Use scalable units for
CSS properties that need to change: font-size and line-height" rather than "Use
these units...".
Directly following that we must also clarify the use of the phrase "relative
positioning": when a CSS designer hear that words he think about a CSS rule
like this: #box { position: relative; } [7]. But, in itself, a positioning scheme
isn't related to accessibility.
When you talk about relative positioning I think that you mean a concept like
"use liquid design" rather than a specific CSS positioning scheme. It is wrong
to advise designers to use a specific positioning scheme. Instead, i.e., we
should tell them that a liquid design is more accessible than a fixed design,
no matter which technique they use to obtain that. Obviously we must first justify
this suggestion!.
These terminological problems are really serious: I've hardly discussed, here
in Italy, with tricky designers that keep on using their beloved pixels for
text sizing because these are relative units as checkpoint 3.4 of WCAG 1.0 suggest
(no matter if partially sighted people using IE/WIN cannot resize them).
Marco Bertoni
--
Referente Regionale IWA Liguria
International Webmasters Association ITALIA
Fax Verde: 800 12.64.96 - Web Site: http://www.iwa-italy.org
[1] http://www.w3.org/TR/WCAG20/appendixD.html
[2] http://www.w3.org/TR/WCAG20/guidelines.html#visual-audio-contrast
[3] http://www.w3.org/TR/WCAG20-CSS-TECHS/#syntax-data-types
[4] http://www.w3.org/TR/CSS21/syndata.html#length-units
[5] http://www.w3.org/TR/CSS21/fonts.html#font-size-props
[6] http://www.pubbliaccesso.it/normative/DM080705-A-en.htm
[7] http://www.w3.org/TR/CSS21/visuren.html#relative-positioning
Status: open
Working Group Notes: [TEAMA] [HOLD]
Resolution Working Notes - Unapproved:
Related Issues:
Assigned To: Nobody
Last Edited: 20060711034443
Sort Terms: font cognitive
Document: WCAG 2.0 Guidelines
Submitter: Henny Swan <henny.swan@rnib.org.uk>
Affiliation: Royal National Institute of the
Blind
Comment Type: substantive
Location: meaning
Comment:
Comment: No mention is made of presentation of text i.e. left aligned vs. justified/right
aligned text, long lines, multiple columns, overuse of different styles etc.
Proposed Change:
Add in.
Status: open
Working Group Notes: [TEAMB]
{SM] Would this be covered under "Principle 1: Content must be perceivable:
Guideline 1.3 Ensure that information and structure can be separated from presentation:
1.3.5 Information required to understand and operate content does not rely on
shape, size, visual location, or orientation of components. [How to meet 1.3.5] "
Aug 14, Clarification from commenter:
Hi Lorretta,
Really what I am wondering is if there should be a mention of how text
is presented as this is important to most if not all users as poorly
presented text can be really problematic to read. There is no specific
mention in WCAG 1.0 and I have found that on some sites that we audit
there is a need for a checkpoint on how text is presented.
The issues that need to be addressed are:
- avoiding centrally aligned text
- avoiding justified text
- avoiding chunks of italic text
- avoiding overuse of different styles on individual pages and in sites
The guideline could read something along the lines of "Ensure text is
easy to read" and the success criteria could then specifically address
each issue i.e.:
- paragraphs of text are not justified or centrally aligned
- paragraphs of text are not italicised
- text styles are used to back up structural change only (i.e. styles
are used for headings etc to help the user differentiate different types of
content)
This is obviously a guideline that would also very much help users with cognitive
and reading problems as well.
Does that help clarify the issue?
Henny
Resolution Working Notes - Unapproved:
@@Partial Accept
@@ Response to Commenter:
The working group believed that this scenario is covered under "Principle 1:
Content must be perceivable: Guideline 1.3 Ensure that information and structure
can be separated from presentation." In particular SC 1.3.5 "Information required
to understand and operate content does not rely on shape, size, visual location,
or orientation of components."
Related Issues:
Assigned To: Nobody
Last Edited: 20060814134229