Re: svg textLength issue (and a little thing about use...)

[there is a strong chance that emails from chris and I
will overlap on this]

On Wed, 13 Nov 2002, Jim Ley wrote:

> > > The textLength attribute on SVG's textLength causes accesibility
> > > problems for users who use their own stylesheets to overide author
> > > selections.
> >
> > This is incorrect. There are several related but distinct things here:
> 
> No, it's clearly correct, the demonstration at
> http://jibbering.com/2002/8/svg-textlength.svg
> shows it clearly.

We agree that the combination of textLength and font-size can 
cause troubles. As Chris said, textLength is for a particular
*required* use case. 

> > - variations in font metrics between platforms can result in slightly
> > overlaping text, a problem that textLength takes care of
> 
> Certainly, one solution to our problems would be to limit textLength to
> +/-20% of the viewers calculated length, that would still mean that the
> text characters did not overlap each other.

You can't guarantee that. The font could have weird kerning that
means that characters overlap no matter what. Text on a path
has a similar problem (curvy paths could create overlapping text).
However, all this is not as relevant than the next point...

> > Yes. And if there was no textLength specified, they would also get a
> > decrease in legibility because of overlap with other text or graphics.
> >
> > They should not do that, but should use zoom instead.
> 
> In discussing my original problem with a member of the WAI working group,
> she made it clear that zoom everything was not an acceptable solution in
> the general case (unfortunately it seems the archive isn't available), I
> assume the WG took input from WAI during discussion of the issue, can it
> be explained why zoom all is appropriate?

No. We were not told why zoom is inappropriate during SVG 1.0. I asked
Wendy (from WAI) this yesterday, but I think she didn't see the
question buried in a long email.

However, I really can't see why a user would prefer setting the font
size over zooming. Zooming is the only way they can be sure they won't
get less information (things won't overlap any more than before). Not
only that, the context remains the same (think of what would happen
on a map if you simply increased the font size of all the text).

Also, this feature has been around for a long time. SVG 1.0 had a 
pretty strong review from WAI and these features became a Recommendation.
(Note, I'm not saying that means they are perfect)

> > Systems that do not do reflow cannot use the font-size property to
> > make text larger for increased legibility. They need other methods
> > that prevent overlap, such as zoom.
> 
> I take this means that the SVG Working Group are removing the ability for
> users to use a user stylesheet to overide the sizing of text?  If a user
> should not do it, why is it a requirement?

We require support of user style sheets. We don't say how a user
should use them. e.g.

svg {
  display: none;
}

> However I do not agree that users do not need to do it, also, resources
> such as:
> http://www.w3.org/TR/SVG-access/
> state:
> 
> | This makes it easier for a user to override styles for different
> | classes of elements when necessary. For instance, users with
> | low vision or with color deficiencies might need to override
> | style properties to read the text.
> 
> Which gives clear indication that users styling text is appropriate.

Yes, they could turn off stroking or change the color to something
that contrasts with the other graphics. If they want to see
things bigger, then they should zoom.

> There are 3 solutions to the issue that I can see:
> 
> 1. Provide a way to overide textLength in CSS.

I think this is definitely worth investigating.

> 2. Remove the ability to have a user stylesheet set the size of fonts,
> and include a zoom: css attribute, to replace the functionality.  (or
> make it a conformance requirement to make the same available via menus, I
> prefer the css approach as a more unified one.)

There are already UA conformance requirements on this issue.
The CSS route needs investigating.

> 3. Limit text lengths power to be +/-20% of the viewers calculated length
> (20% is a guess whatever is appropriate)

I don't think this will help at all.
A script (or animation) could change the number of
characters.

> Marking the issue as "incorrect" is not an appropriate response.

True.

I think we can all see and understand the problem. The reason
we are rejecting it is because we don't think it is something
users should do (ie. they have a better solution available).
However, we do agree to spend some time (in SVG 1.2, since it would be
a new feature) working with you and WAI to come up with a remedy.

How does this sound?

Dean

Received on Wednesday, 13 November 2002 08:37:20 UTC