Re: We all must attend LVTF next week especially people with low vision

That works today. Will it work with web components?

An SC is normative and techniques are not. Something, that works on HTML
DOM may not work with web components.

We do not hold authors accountable if their technology cannot provide but
we ask them to test for support when it exists.

The reason we have this problem today is because WCAG 2.0 did not make
visual accommodation part of 1.3.1. So we need to include the bed rock
essentials as new SCs.

We need that ability to prescribe spacing, font-family and color
established as normative requirements.

Let me show you how a normative requirement influences technology
development.

In the Flex Box Module <https://www.w3.org/TR/css-flexbox-1/> document of
CSS the following language is inserted to support 1.3.2 (Meaningful
Sequence) a normative requirement.



*Authors must use order
<https://www.w3.org/TR/css-flexbox-1/#propdef-order> only for visual, not
logical, reordering of content. Style sheets that use order
<https://www.w3.org/TR/css-flexbox-1/#propdef-order> to perform logical
reordering are non-conforming.*
I doubt this disclaimer would be placed in the module without a normative
criterion to support it.

These need to be normative. Informative is forceful enough.

As new modules are added to HTML5 they will  play on browsers that support
extensions using JavaScript accessibility spacing, font-family, color. We
can hold authors to not reducing this accessibility in HTML5 new content
that is not in the DOM.

I think that is my point.

Wayne



On Sun, Jan 15, 2017 at 5:38 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> Ø  I think we should address it as follows. Right now the claim is that
> the ability to change spacing already exists for HTML, so it shouldn't be
> an SC. The same argument will be used for font-family. I say we modify our
> SCs to be element level access to spacing, font-family and color. The
> problem is easily solvable with ARIA. It is not without. We don't have to
> look far at all for a failure. The W3C  Wiki fails element level
> customization.
>
> Currently if you replace the font-family for all page content you
> generally lose access to font icons.  Is there a known workaround for
> this?  Is this something that can be addressed?
>
>
>
> Jonathan
>
>
>
> Jonathan Avila
>
> Chief Accessibility Officer
>
> SSB BART Group
>
> jon.avila@ssbbartgroup.com
>
> 703.637.8957 <(703)%20637-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/>
>
> *See you at CSUN in March!
> <http://info.ssbbartgroup.com/CSUN-2017_Sessions.html>*
>
>
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.
>
>
>
> *From:* Wayne Dick [mailto:wayneedick@gmail.com]
> *Sent:* Saturday, January 14, 2017 5:01 PM
> *To:* public-low-vision-a11y-tf
> *Subject:* We all must attend LVTF next week especially people with low
> vision
>
>
>
> Things are going terribly for any customization.  WCAG WG has a visceral
> reaction to making developers do anything to support font-family, spacing
> or color. The fundamental attitude is that developers shouldn't have to
> lift a finger. If they object to something and we address it. They bring up
> something else. I really think they want to say Screen Magnifications
> Systems are all we need, and be done with it.
>
> I think we should address it as follows. Right now the claim is that the
> ability to change spacing already exists for HTML, so it shouldn't be an
> SC. The same argument will be used for font-family. I say we modify our SCs
> to be element level access to spacing, font-family and color. The problem
> is easily solvable with ARIA. It is not without. We don't have to look far
> at all for a failure. The W3C  Wiki fails element level customization.
>
> As soon as I'm done with this I will write up font-family with an element
> level orientation.
>
> Next I think a test should be to place a style element at the end of the
> author's <head> that resets the spacing, font-family or color use
> !important. This will be an author level !important that will be broken by
> a style at the element level with !important. That will ensure that a
> mechanism exists, namely stylish.
>
> If our efforts fail, I think we need to work on putting as many people
> with low vision as we can on the steps of
>
> W3C MIT CSAIL
> 32 Vassar Street
> Building 32-G528
> Cambridge, MA 02139-4307
>
> To protest unfair treatment.
>
>
>
> Wayne
>
>
>