Re: SVG, Style, Resizing, Etc.

Response at AG::
At 11:55 AM 2000-10-05 -0500, Jon Gunderson wrote:
>Response in JRG:
>At 08:42 AM 10/5/2000 -0400, Al Gilman wrote:
>>At 04:51 AM 2000-10-05 -0400, Ian Jacobs wrote:
>> >>
>> >> 3. The resizing of vector graphics like SVG I do not think are addressed
>> >> in the guidelines.  I think the group should discuss this. I will add it
>> >> to the issue list for discussion on 10 October.
>> >
>> >IJ: Please help me understand the issue at hand.
>> >
>> >1) For the case of SVG, the requirement in question (the ability to
>> >   recsize content) is part of conformance (and thus covered by
>> >   UAAG 1.0 checkpoint 6.2). Refer to section G.7 [1]:
>> >
>> >   "For interactive user environments, facilities must exist for
>> >    zooming and panning of standalone SVG documents or
>> >    SVG document fragments embedded within parent XML documents."
>> >
>> >   There are other relevant conformance requirements in that section.
>> >
>>
>>AG::
>>
>>[There's nothing to keep us from clarifying the issue by mail prior to the
>>telecon.]
>>
>>This is good.
>>
>>Do the "other ... conformance requirements" determine what happens about
>>the boundary in the layout canvas between the SVG content of an embedded
>>SVG object and the other content of the parent XML document?  Turning a
>>navigation button into a scroll region because the user asked for it larger
>>would not exactly be swift.
>>
>>Al
>
>JRG: Al are you saying that the SVG specification is good enough for us 
>right now or do you think UA should support more explicitly the 
>accessibility of scalable vector graphic renderings?
>

AG::

Sorry, I am carefully ducking "the ultimate question."  I am not saying it
is sufficient or not sufficient.  

What I am saying is that what Ian found in the SVG specficiation does not
appear to require that the document containing the SVG Object make space
for the SVG object to get bigger.  If all we get when we zoom the SVG
button is a scroll region -- where the scroll bars will consume all the
space allocated for the button to begin with -- that's probably not usable.

I was not making a firm statement that an additional checkpoint is required
or is not required.  But I was asking that people decide if resizing the
graphic and forcing a reflow is important, how important, and consider if
that shouldn't be mentioned.

An alternative to a requirement to be able to resize graphics, including
their layout allocation would be to have something like the "always expand
ALT text fully" rule in IE.  Here the rule is that if the text in the SVG
buttons is requested to be larger, that the host document and application
resize the layout region allocated to the SVG object to accomodate.  Maybe
this is automatic per the specs as of today.  I am just suspicious of the
way layout is shared across formats as not well described in the format
specs, so I was not willing to say that "the format spec is sufficient"
until we had a clearer model from the Working Group of the functionality
desired.  Then we can give a little concerning what is required if what is
desired is hard but there is an easy alternative that basically works.


Al

>Jon
>
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Division of Rehabilitation - Education Services
>MC-574
>College of Applied Life Studies
>University of Illinois at Urbana/Champaign
>1207 S. Oak Street, Champaign, IL  61820
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: jongund@uiuc.edu
>
>WWW: http://www.staff.uiuc.edu/~jongund
>WWW: http://www.w3.org/wai/ua
>

Received on Thursday, 5 October 2000 15:34:27 UTC