Thread Subject: Re: 1-G - Text size

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Gregg Vanderheiden
Date: Mon, Mar 24 2008 10:25 PM

Hi Mary,



Ok lets see what we can do here.



First - where did you get the large button phone and security issues from?

The provisions can be met with 12 point type if clear. Smaller depending
on font. There is no need for large button phones in lobbies.

And the font size required on a display is already standard on many (most?)
mainstream phones - so it is unclear how new security issues would be
involved.



Can you explain the concern here? Or recheck them prior to the call?



Anything that can be read from about 5.25 ft if you have 20/20 vision would
be good enough. I don't have 20/20 vision and I can read most of the text
on most of the buttons on my phones as they are - and could read the rest
if they didn't print them in very thin letters. They don't need to be
large buttons to fit text that would pass this.



Regarding the notes:

I think some already do what you want as notes but others might need to be
included.

For example Note 1: explains that if the labels are 'not required for
operation or use' then the provision already does not require they be
available otherwise. Since the provision already says that it only applies
to text "required for operation or use" this isn't anything new - or a new
exception. It is pointing out what the provision already says. So this
could stay a note.





However if that is not felt to be clear - then putting them in as
provisions might be the right thing to do.





So lets take a crack doing what you suggest. Since this is getting very
long - I made it into bullet form




1-G - Text size


For all public or shared products there must be at least one mode where all
information that is required for product use and is provided in text or
images of text is readable by people with 20/20 vision at 3.5 times their
typical viewing distance and where the mode is the default mode or the
method for activating the mode meets this requirement except:

* Caption display: This requirement does not apply to the caption
decoding functions of products that are governed by U.S. Federal
Communications Commission (FCC) regulations 47 CFR 15.119 or to devices that
provide equivalent functionality as stipulated by 4-A - Caption Processing.

* Logos and Certifications: Safety labels, regulatory labels, and
other marks (such as logos and certifications) are not included except where
they are required by the user "for product use".

* Tactile Equivalents: If other means of visually conveying the
information in the label or instructions exists (e.g. uniquely tactilely
discernible through shape), and the text is not "required for product use"
and the text size requirement does not apply.

o For example, a phone-like numeric keypad (with nib) or a tactilely
unique cluster of arrow keys are usable without labels while softkeys (where
the function changes and must be read from a display) would not be usable
without the label.

* Personal devices: Personal or personally assigned devices are not
covered unless all users must use the same product (or same type of product)
(e.g. policy or in order to work with system software or procedures). In
that case it constitutes a 'shared device' since all must use the same one
(the same type) and that product (or type) would need to meet provision.

* Use of text file: Providing text in an accessible file on a device
meets this requirement for information that is not location specific (e.g.
labels are location specific).

* Application to Software: Software that is not associated or
purchased with any particular hardware (so the text does not have a physical
size until it is displayed) can be evaluated on any typical display that the
software is intended to work with.



RE magnifier question. We generally have not required that people carry AT
around with them to operate public devices.








Gregg






Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

If Attachment is a mail.dat try http://www.kopf.com.br/winmail/






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Brooner
Mary-AMB004
Sent: Monday, March 24, 2008 8:48 PM
To: TEITAC Committee
Cc: Rebecca Schwartz
Subject: Re: [teitac-committee] 1-G - Text size

All - I want to clarify a point TIA made below re Public Use phones. Even
if we can agree to exempt telephone keypads as proposed below, i.e. to make
note 2 and exemption, there remains the issue of keys that are fixed, not
soft, such as Mute button, Hold button, Line 1 or Line 2. Because these
keys are always used for the same purpose, they are labeled in ink on the
hardware.



As proposed by Gregg, on Public Use devices those buttons would have to
extra large keys, if TIA understands the proposed provision correctly.
These buttons are needed for operation of the device but are not a part of
the keypad. Thoughts on how we might address this?



Thank you.



Mary Brooner

TIA Representative




_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Brooner
Mary-AMB004
Sent: Monday, March 24, 2008 2:41 PM
To: TEITAC Committee
Cc: Rebecca Schwartz
Subject: Re: [teitac-committee] 1-G - Text size

TIA appreciates Gregg's efforts to find consensus language with the FONT
SIZE issue, but we still have some concerns.



For a start, while some of the notes are good, they are just notes. TIA
believes that especially Notes 1,2 and 3 need to be exemptions in the
proposed standard itself. The effect of these changes would be:



Note 1: Required labels on a device, not required by the user "for product
use" would be exempted.

Note 2: So long as the numeric keypad has a nib and and the cluster of
arrow keys are usable without labels while soft keys, would be exempt.

Note 3: Personal or personally assigned devices would be exempt except in
the case of a "shared device."



If there is agreement on incorporating the changes above into the proposed
standard itself, I will work on drafting specific revised text..



In addition, there is concern among TIA members that Gregg's revised
proposed standard, would still require Public Use phones to be large keypad
and button devices. This would put at risk confidential info, such as access
numbers. It would also mean that in an enterprise environment where there
are lobby phones or hotel room phones, all would have to be large button
handsets OR there would have to be a separate line of handsets in the
Enterprise for these limited public environments. If a separate line of
handsets is implicitly required, it would be a significant expense to both
the Manufacturers and the procuring organization. The question was raised
once again, how does a requirement on manufacturers to build products that
procuring organizations likely will not buy solve a problem? The reality is
that this has been the real experience of too many manufucturers when
attempting to meet 508 standards requirements that don't achieve the
appropriate balance to also sell in the general marketplace.



Lastly, in response to Gregg's note suggesting that people with
really low vision can be expected to carry a magnifier, but people with low
vision may not. Gregg's proposed standard in the 2nd sentence is "This mode
must be the default mode unless the activation method for that mode can be
done at 3.5 times the typical viewing distance or the product automatically
sets itself to that mode for users who require it"



TIA asks a scoping question.... If a person has low vision but not
so low as to carry a magnifier, does that warrant a 508 standard that
requiresall products to have their default setting optimized for a low
vision user? Effectively, to meet this provision would also require a
complete separate product line versus designing a product to leverages
features that provide optional settings for persons with low vision.



Thank you,



Mary Brooner

TIA Representative to the TEITAC




_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Saturday, March 22, 2008 12:43 PM
To: 'TEITAC Committee'
Subject: [teitac-committee] 1-G - Text size

OK Wish me luck. Here is an attempt to address the comments etc to see if
we can come up with something to cover this important area - that is not
covered elsewhere. Hopefully this will allow us to work toward consensus
on this provision.



First - and most important change - it is limited to public or shared
products. These are things that a person cannot modify, mark up, or buy
their own version of. It also can be things that they don't know about in
advance of encountering.



This allows personally (or personally assigned) cell phone, keyboards, etc
to be excluded.



This does open up the problem talked about on other provisions - that an
agency would buy one type of cell phone (for example) and then write
software that only works with that phone (or type of phone). The user with
low vision may know of phones they could use - but none of them work with
the software - so they have to use a phone that has only small print on it.
I don't know how to get around this. The best I could do was the note that
says 'if you all have to use the same type of personally assigned device
then it constitutes a 'shared device' since all must use the same one (the
same type).





Summary of features

- applies only to public or shared devices !!

- allows personally (or personally assigned) cell phone, keyboards,
etc to be excluded. (except where user cannot use any but one type of
device)

- removes the font sizes from the notes - since people were reading
that as a required font size.

- removes the 4.5 inch screen note (same reason)

- moves safety label exception to a note since it is already
covered but needs to be made explicit

- adds detail to note on keys that don't need labels in order to
use the product (tactilely unique)

- removes the note "See also 3-D-User Preferences for software
products that run on operating systems that provide a function to set user
preferences." to reduce clutter but this can be added back if desired.

- Adds a note for software that says "Software that is not
associated or purchased with any particular hardware (so the text does not
have a physical size until it is displayed) can be evaluated on any typical
display that the software is intended to work with." This eliminates all
the pixel calculations (which will not remain valid) and also separates
stand alone software from software in a product.




Try this one on for size. (sorry - not intended)


gregg





1-G - Text size (Discussed Feb 7, 12, 19, March 18)


For all public or shared products, there must be at least one mode where all
information that is required for product use and is provided in text or
images of text is readable by people with 20/20 vision at 3.5 times their
typical viewing distance. This mode must be the default mode unless the
activation method for that mode can be done at 3.5 times the typical viewing
distance or the product automatically sets itself to that mode for users who
require it. This requirement does not apply to the caption decoding
functions of products that are governed by U.S. Federal Communications
Commission (FCC) regulations 47 CFR 15.119 or to devices which provide
equivalent functionality as stipulated by 4-A - Caption Processing.

Note 1: Safety labels, regulatory labels, and other marks (such as logos
and certifications) are not included unless for some reason they are
required by the user "for product use".

Note 2: If other means of visually conveying the information in the label or
instructions exists (e.g. uniquely tactilely discernible through shape),
then the text is not "required for product use" and the text size
requirement does not apply. For example, a phone-like numeric keypad (with
nib) or a tactilely unique cluster of arrow keys are usable without labels
while softkeys (where the function changes and must be read from a display)
would not be usable without the label.

Note 3: Personal or personally assigned devices are not covered unless all
users must use the same product (or same type of product) (e.g. policy or in
order to work with system software or procedures). In that case it
constitutes a 'shared device' since all must use the same one (the same
type) and that product (or type) would need to meet provision.

Note 4: Providing text in an accessible file on a device meets this
requirement for information that is not location specific (e.g. labels are
location specific).

Note 5: Software that is not associated or purchased with any particular
hardware (so the text does not have a physical size until it is displayed)
can be evaluated on any typical display that the software is intended to
work with.

Rationale
The goal of this provision is to support people with low vision. People with
vision worse than 20/70 typically use an assistive device, so this provision
is aimed at supporting those with vision between 20/40 and 20/70.

* For people with 20/20 vision viewing text at 40 cm (15.7 inch), 8pt
type is a small but acceptable type size for running text and somewhat
smaller text could be used for common labels where it is mostly identifying
which key is which rather than having to read novel and/or un-expected
information.
* For people with 20/70 vision, an acceptable size for running text is
approximately 28pts at 40 cm viewing distance and somewhat smaller text
could be used for common labels
* If we assume users with low vision can move in closer (half distance
- 20 cm) to view text (and that their glasses allow this), 14 pt type would
provide type that subtends the same visual angle (as 28 pt at 40 cm).

Although many users with low vision will use close vision coupled with
glasses that focus their vision - it is too hard for designers to work off
of this - and all glasses are custom. The 3.5 distance with 20/20 gives a
measure that is repeatable and will yield text that is legible to who need
larger clearer type. It also automatically allows text to be smaller if it
is clear and requires it to be larger if it, for example, used very thin
stem width.

Some users with low vision have a field of view limitation. They can use
small print modes if available. In general though, signage and other
existing access regulations are based on the assumption that larger print is
more universally accessible for people with low vision than print that is
small to accommodate people with field of view limitations who cannot step
back to shrink the size of the text in their view. (Note also that this
provision does not require very large text - just text that is not small.

At a workstation, it is reasonable to assume that special reading aids (such
as a moderate magnifying glass) would be available even if user's vision is
in the range of 20/30 to 20/70, and fonts can therefore be smaller. The
sizes for devices designed to be used away from a person's workstation are
aimed at those with low vision but not very low vision (beyond 20/70). This
is based on an assumption that:

* People with 20/70 vision or better would not usually carry a
magnifying device with them.
* People with worse than 20/70 vision would usually carry portable
optical magnifying devices (including special glasses) with them.

The Note "Software that is not associated or purchased with any particular
hardware (so the text does not have a physical size until it is displayed)
can be evaluated on any typical display that the software is intended to
work with." eliminates all pixel calculations (which will not remain valid)
and also separates stand alone software from software in a product.

The provision is limited to public or shared products. These are things
that a person cannot modify, mark up, or buy their own version of. It also
can be things that they don't know about in advance of encountering. This
allows personally (or personally assigned) cell phone, keyboards, etc to be
excluded. However, this does open up the problem talked about on other
provisions - that an agency would buy one type of cell phone (for example)
and then write software that only works with that phone (or type of phone).
The user with low vision may know of phones they could use - but none of
them work with the software - so they have to use a phone that has only
small print on it. In this case we believe the issue can be addressed with
a note that explains "Personal or personally assigned devices are not
covered unless all users must use the same product (or same type of product)
(e.g. policy or in order to work with system software or procedures). In
that case it constitutes a 'shared device' since all must use the same one
(the same type) and that product (or type) would need to meet provision."

Rationale for Note 6: The FCC rules and the CEA-708 standard are designed to
enable DTV receivers to display caption text in a window on the screen that
is readable but also does not obscure the video content. Caption text is
displayed in a window relative in proportion to screen size, but an absolute
text size is not defined. Current DTV receivers with 708 decoders must
support standard, small, and large caption text size and support the ability
of the viewer to choose size, but absolute text size is still relative to
the size of the display. The "windowing" environment of CEA-708 was designed
to allow caption providers to create a targeted safe area for caption
display while allowing consumers to grow or shrink captions within that
window. Even at the large caption text size, however, very small screen
sizes may not permit display of caption text in compliance with this
provision. For video programming, this requirement can best be met by
ensuring that displays located in public places or at a person's workstation
are large enough to display caption text so that it meets the requirements
of this provision.

Open issues

* Remove or edit second sentence to make the scope clear.





Gregg

------------------------

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at http://tinyurl.com/dho6b

If Attachment is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University