Re: Font Family failure

On 14/01/2017 16:23, Wayne Dick wrote:
> The real problem is that WCAG 2 overlooked visual style as an important
> accessibility support.
>
> I caught that  problem last night. I stayed up late. Yes the narrow
> solution will work for that case, but what about the code
>
> <block-level-element> ...
> <span class='thing1"> Thing 1 </span> ...
> <span class="thing2>Thing2 </span>...
> </block-level-element>
>
> Suppose these spans exist solely to provide visual presentation for
> private reasons of the author. For example: Thing1 was an important
> sales offer and Thing2 was a deadline. Moreover, suppose Thing1 was one
> font-family and Thing2 was another. Your code fails. Probably poor
> design -just to staying in font-family case.
>
> block-level-element, block-level-element *  {font-family: zilch !important}
>
> will set everything in block-level-element font-family = zilch.
>
> What can the author do? A lot. There are other elements like, i, b, em,
> strong etc. that indicate  presentation change. Use one of those. If
> block level element is one of h1, ..., h6, use  role= 'heading' .
>
> Jason, we probably need an ARIA role like "visual-style" to indicate
> that a void element like <span> or <div> is just for presentation.

Sorry Wayne, you lost me now...what exactly are you getting at?

While the page at 
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Line_Length uses 
<span>s nested inside <h1>, <h2> etc headings, they are not there to 
convey any extra meaning. They're semantically neutral, and they just 
happen to be part of the code. So you're not losing any meaning by 
making your custom style more specific.

You now seem to be intimating that you don't want to make your styles 
more versatile (with addition of the * universal selector) because that 
may remove styling in cases where authors did use different <span>s or 
similar to visually distinguish parts of a heading or something while 
also conveying meaning?  Well, that would already be a failure of WCAG 2 
today (failing 1.3.1 for instance), so it's nothing to do with 
stylability or that authors somehow "won't allow a change".

The fundamental answer to your problem still remains that YOUR custom 
styles need to be written in a way that accounts for the variety of 
valid and semantically correct content that's out there. And yes, 
sometimes there will be a span, or maybe more, inside a heading, for 
whatever reason. It doesn't always mean that the author mistakenly used 
a span instead of a more meaningful element - the base assumption, since 
spans etc are semantically neutral by definition, has to be that they're 
only presentational hooks that do not convey meaning, so that your 
overrides (when coded robustly to account for them as, say, child 
elements of headings) won't wipe away any meaning conveyed purely 
through visuals.

You can't mandate that authors never do things like adding <span>s 
inside <h1>s or similar because that makes it more difficult for you to 
write simple overrides.

Your override styles need to be robust enough in terms of selectors to 
effectively override different types of content structures.

The fact that authors need to use semantic markup to convey meaning is 
orthogonal to your original problem (since the <span>s present in the 
headings are not trying to convey any particular meaning, they're 
neutral and just happen to be there, and your very simple custom styles 
were not coded with that possibility in mind).

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Saturday, 14 January 2017 19:52:33 UTC