Re: lvtf-ACTION-70: Write font sc

Hi Jon,

I added "without scrolling in more than one direction" because Wayne
had it in his first draft, which I suspect is based on Richard Ishida
advice to Shawn:
https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2016Sep/0010.html

Is that right, Wayne?

Kindest regards,
Laura

On 9/6/16, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
>> Except for captions and images of text, text can be resized without
>> assistive technology to a user agent's maximum and minimum without
>> scrolling in more than one direction and without loss of content or
>> functionality.
>
> Sounds good.  I have two questions. Are we concerned that if we state the
> user should only be required to scroll in one direction someone might come
> up with something for LTR that scrolls horizontally but not vertically.
> Would we be ok with that?   Also is the term direction problematic, that is
> one might think you can scroll down but not up?
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> jon.avila@ssbbartgroup.com
> 703.637.8957 (Office)
> Visit us online: Website | Twitter | Facebook | Linkedin | Blog
> Check out our Digital Accessibility Webinars!
>
>
> -----Original Message-----
> From: Laura Carlson [mailto:laura.lee.carlson@gmail.com]
> Sent: Tuesday, September 06, 2016 3:35 PM
> To: Low Vision Accessibility Task Force; Wayne Dick; Jonathan Avila
> Subject: Re: lvtf-ACTION-70: Write font sc
>
> Hi Wayne, Jon, and all,
>
> Would it help to reuse some of the verbiage from the current 1.4.4 Resize
> text? [1]. That reads, "Except for captions and images of text, text can be
> resized without assistive technology up to 200 percent without loss of
> content or functionality."
>
> Does the following description say what we mean?
>
> == Description ==
>
> Except for captions and images of text, text can be resized without
> assistive technology to a user agent's maximum and minimum without scrolling
> in more than one direction and without loss of content or functionality.
>
> Then perhaps we could adapt the Testability section that I put together for
> the Size of all elements SC [2] and change the word "Zoom" to "text"? Would
> it be worth considering something such as the following?
>
> == Testability ==
>
> 1. Display content in a user agent.
> 2. Increase text size to the maximum.
> 3. Decrease text size to the minimum.
> 4 Check whether text scales and is perceivable without scrolling in more
> than one direction. (e.g. boxes do not overlap, controls are not obscured or
> separated from their labels, etc.).
>
> Expected Results:
>
> Check #4 is true.
>
> What do you think?
>
> Kindest Regards,
> Laura
>
> [1]
> https://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-scale
> [2] https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Size_of_all_elements
>
>
> On 9/6/16, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
>> Ø  4. Hidden indents. I don't even know what code causes them, but
>> wiki pages have them.
>>
>> From what I can tell on wiki – it’s list styles override anything you
>> create in a page even with HTML and CSS – so they must be using
>> !important.
>> Perhaps in the indention issue they are using lists for indention
>> where they should not be?
>>
>>
>> Ø  6. Absolute placement of headings
>> Yes, absolute and fixed position of content is very problematic for zoom.
>> Also problematic are snap to scroll pages that scroll by page and chop
>> off content with overflow preventing users with from seeing the whole
>> screen’s content.  When the user tries to scroll they end up on the next
>> page.
>> Also in these situations are zoom hijacking – that is page zoom with
>> the mouse doesn’t work as it is taken over to do something else.
>> Jonathan
>>
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
>> 703.637.8957 (Office)
>> Visit us online: Website<http://www.ssbbartgroup.com/> |
>> Twitter<https://twitter.com/SSBBARTGroup> |
>> Facebook<https://www.facebook.com/ssbbartgroup> |
>> Linkedin<https://www.linkedin.com/company/355266?trk=tyah> |
>> Blog<http://www.ssbbartgroup.com/blog/>
>> Check out our Digital Accessibility
>> Webinars!<http://www.ssbbartgroup.com/webinars/>
>>
>> From: Wayne Dick [mailto:wayneedick@gmail.com]
>> Sent: Tuesday, September 06, 2016 2:21 PM
>> To: Jonathan Avila
>> Cc: Low Vision Accessibility Task Force
>> Subject: Re: lvtf-ACTION-70: Write font sc
>>
>> I am not sure how to change "the document enables". The issue is this.
>> I do not want to imply that the author needs to build in AT, but what
>> I would like to say is "the author shall introduce no barriers to ...".
>> I have written a compiler that maps user's non-numerical visual
>> preferences into actual numerical and string parameters that can be
>> used for changing the visual presentation proposed by the font, text
>> and color transformations. The problem is barriers to block level
>> linearization.  Some pages just go blank if you try to modify
>> positioning. Here are a few barriers.
>> 1. In line style with !important parameters.
>> 2. JavaScript that prevents vertical scrolling.
>> 3. Run-time positioning.
>> 4. Hidden indents. I don't even know what code causes them, but wiki
>> pages have them.
>> 5. em based margins and padding.
>> 6. Absolute placement of headings
>> That's all I can think of for now. Without obstacles like this you can
>> linearize a page and achieve every visual style change we need. We can
>> make narrow normal print columns. Color is no object. We can make
>> "uge" print as Bernie Sanders would say. Word wrapping would be no
>> problem.
>> Thanks for the comments Jon.
>> Wayne
>>
>>
>>
>> On Tue, Sep 6, 2016 at 8:54 AM, Jonathan Avila
>> <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote:
>> Wayne, thank you for putting this together.  The phrase “The document
>> enables the user to change …”  seems to imply that we are going to
>> require
>> on page controls for adjusting fonts.   Should we use a term like the
>> document does not override the user’s ability to ….   I’m not sure what
>> the
>> best term is – but perhaps a phrase like that or “the document does
>> not prevent”, might be good.
>>
>> Jonathan
>>
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
>> 703.637.8957<tel:703.637.8957> (Office) Visit us online:
>> Website<http://www.ssbbartgroup.com/> |
>> Twitter<https://twitter.com/SSBBARTGroup> |
>> Facebook<https://www.facebook.com/ssbbartgroup> |
>> Linkedin<https://www.linkedin.com/company/355266?trk=tyah> |
>> Blog<http://www.ssbbartgroup.com/blog/>
>> Check out our Digital Accessibility
>> Webinars!<http://www.ssbbartgroup.com/webinars/>
>>
>> From: Wayne Dick
>> [mailto:wayneedick@gmail.com<mailto:wayneedick@gmail.com>]
>> Sent: Monday, September 05, 2016 3:04 PM
>> To: Low Vision Accessibility Task Force
>> Subject: Re: lvtf-ACTION-70: Write font sc
>>
>>
>> Font Resize: The document enables the user to change font-size down to
>> and up to the limits provided by the user agent. The resulting font
>> change will fit in any enclosing boxes and will not result in need to
>> scroll is more than one direction.
>>
>> Font Family: The document enables the user to change the font family
>> to any family generally available to document authors.
>>
>> Text Style: The document enables the user to change the style of text
>> (italic, bold, normal, etc.) to any other style or to any other font
>> family and style that is available to the user agent.
>>
>>
>>
>>
>>
>> 2016-08-25 8:17 GMT-07:00 Low Vision Accessibility Task Force Issue
>> Tracker
>> <sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>>:
>> lvtf-ACTION-70: Write font sc
>>
>> http://www.w3.org/WAI/GL/low-vision-a11y-tf/track/actions/70
>>
>> Assigned to: Wayne Dick
>
> --
> Laura L. Carlson
>


-- 
Laura L. Carlson

Received on Tuesday, 6 September 2016 19:51:46 UTC