Re: Headings and ARIA substitutes

On 16/06/2016 21:19, Wayne Dick wrote:
> One thing that is being discussed in the LVTF and the Cognitive Task
> Force is the notion of customization. That is, reconfiguration of the
> author's presentation. Regarding the reconfiguration of visual to audio,
> WCAG 2 was very clear and clean. This was not the case for visual
> presentation to new visual presentation. The above context is needed to
> address heading presentation.
>
> Size is a poor discriminant in the large print world. Must people with
> reduced visual acuity (a large LV group) need far more than 200%
> enlargement. 400-900% is more like it. Now if headings are bigger, there
> isn't any screen space left. The need for customization is demonstrated
> here. If one can see color, color is a good discriminator. If not a
> prefix like . For H1, ..  For H2, ... For H3, ... . For H4 etc is
> useful. Depending on the individual's functional vision differences
> presentations could be implemented differently.
>
> This is an example of differences that could be implemented in HTML /
> CSS with proper structure.
>
> Given the enormous flexibility of HTML / CSS and Javascript, and the
> remarkable rendering power of all major browsers, it is surprising how
> little of this capability has be applied to the needs of people who need
> re-configurable visual presentation.
>
> Regarding the semantic implication of headings: Yes navigation would be
> great for non screen reader users. For WCAG 2.1 we need to focus on
> content, not what UAs can do.

The idea of customisation sound to me like the spirit of what guideline 
1.3 Adaptable *wants* to do 
https://www.w3.org/TR/WCAG20/#content-structure-separation "Create 
content that can be presented in different ways".  Taking the example of 
headings, once a heading (and its level) can be *programmatically* 
determined (which satisfies 1.3.1), a UA can easily provide customisable 
styles for those headings - the way in which these styles are targetted 
obviously then needs to include more than just naive "if it's h1 - h6, 
apply these styles", but more deeply hook into "if this element has a 
native or assigned role of heading, apply these styles based on the level".

Perhaps the understanding/techniques for 1.3.1 need to be expanded to 
emphasise this particular aspect further, in light of low-vision and 
cognitive?

It still feels like authors should, nonetheless, take care that the 
out-of-the-box visual presentation they choose also makes heading 
hierarchy clear, and that this should also be a new SC. And, as James 
Nurthen quite rightly suggests, this is not necessarily a matter of 
picking a size, but can take many forms - i.e. there are many ways 
(possibly quite subjective to audit?) to visually distinguish what's a 
heading, and what different levels of headings are. This, to me, would 
fall under the general "Principle 3: Understandable - Information and 
the operation of user interface must be understandable."

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 Thursday, 16 June 2016 20:35:37 UTC