Re: WCAG violations or accessibility enhancements

Hi Richard

I don’t believe I am confusing semantics with visual appearance. Tag name and structural context should tell us all we need to know about the meaning of the text, and in a properly-considered document schema such as DITA it does so. Workarounds in CSS to make two elements look the same when the markup says they aren't the same are… not optimal, and add complexity when outputting to a number of different formats.

The primary aim of semantic markup is to allow the unambiguous expression of that text in a wide range of communication environments: visual, aural and others (er… tactile? olfactory?).

First problem is that HTML is inadequate for expressing the semantics of a wide range of documents. That’s why schemas for specific document types exist (DITA, TEI, NewsML etc). Even for those it is suitable for, there are problems with ambiguity (the h1 h2 etc problem is one) that are both technical and how-to-use -related (the two dimensions that Duff talked about). But with all its problems, HTML is a very useful ‘lowest-common-denominator’ markup dialect to allow most documents to be expressed in a variety of media.

Second problem is that screen readers, while a boon to humanity, create ease-of-use by assuming that common patterns of markup are universal, and failing to deal with ‘edge’ cases gracefully.

Thus they add a second lowest common denominator for communication, further narrowing the range of communicable intent which can be used on the web while accommodating the needs of screen readers.

Third problem is that ‘accessibility conformance’ is now a requirement in a wide range of web publishing environments and it is largely evaluated by machines and clerks. Formal standards in this area are a brilliant advance and are making large parts of the web usable to a a diverse audience. I lurk here but I’m a big fan of the work that W3C WAI have done and are doing, which is better than we might expect or deserve.

But that work inevitably further narrows the range of expression that is possible.

We all know that making documents accessible actually involves user research, journey mapping, co-design with diverse users, iterative comprehension testing and diligent monitoring of live sites and feedback. Machine-executed testing ought to confine itself to serious errors and ‘failures’ should be confined to things that are failures and not justifiable minority use-cases.

So, please don’t make failure to use hierarchical heading structures a ‘violation’.

best

Mark


> On 3 Mar 2018, at 19:41, Userite <richard@userite.com> wrote:
> 
> Hi Mark,
> What you are missing is that the semantic code for headings is not the same as the styling of what the heading looks like.  In your example of the warning message (safety Alert)  The alert should be given a class for styling, then whenever the alert is to be used it can use the appropriate heading (i.e. one level below the current heading level) but it will still look like all the other warnings for visual users.  This semantic approach thus ensures that the warning message is programmatically tied to the relevant section and makes logical sense to a screen-reader user.
>  
> If you do not use the logical “tree” structure for headings then you are disadvantaging screen-readers in comparison to visual users. 
>  
> If there ever is a need to use unusual structure for headings (I can’t think of one myself)  then you MUST warn screen-reader users and explain the alternative structure that you are using.
>  
> Richard
>  
> From: Mark Barratt <mailto:markb@textmatters.com>
> Sent: Friday, March 02, 2018 4:29 PM
> To: Marc Haunschild <mailto:haunschild@mhis.de>
> Cc: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
> Subject: Re: WCAG violations or accessibility enhancements
>  
> Documents for different purposes and different users may need different structures. ‘Best practice’ is not the same for all kinds of document for all kinds of use, and it is not determinable by mechanical parsing of markup.
>  
> For some kinds of documents (for example instructions, manuals, legislation and reference guides) a strict hierarchy of headings approaches a requirement to make the content structure as clear and as navigable as possible for the user.
>  
> (Even here, there are exceptions: a standard ‘safety alert’ in an operating manual needs to appear near the text which causes it to be needed, and it needs to be consistent with other safety alerts in the text. The safety alert is likely to be a standard block with a standard, say h3, heading. It may appear within a text block where the heading before it is h1 or h4. It’s not wrong.)
>  
> But there are a lot of other kinds of text: novels, news stories, essays, diaries etc which are appropriately or wilfully not bound by hierarchical rules. Their structure may not be hierarchical either visually or semantically. They may, quite reasonably, be hard to follow for sighted or visually challenged readers.
>  
> In a machine-evaluated text, it is reasonable to report a non-hierarchically-structured page to the originator as ‘something you might want to check - hierarchical headings help users and search engines navigate, reference and understand operative texts’, but ‘best practice’ is a stretch, and ‘violation’ is just wrong.
>  
> best
>  
> Mark
> 
>> On 2 Mar 2018, at 15:30, Marc Haunschild <haunschild@mhis.de <mailto:haunschild@mhis.de>> wrote:
>>  
>> Anyway: whenever possible no heading level should be skipped. I agree with this of course. This is best practice. But as a matter of fact, that is not the answer to all real-life problems. Sometimes it is surprisingly difficult to find the best solution. For example when developing a modular content management, where modules can be used in a text and you cannot know, if there is h2, h3 or h4 before it.
>>  
>> So I can give a h5 for this box or the author must choose the correct heading every time he uses this module – because nobody is perfect he may choose h3 after h4.
>>  
> 
>  
> --
> Mark Barratt
> Text Matters
>  
> We help explain things using design | language | systems | process improvement
> 
> markb@textmatters.com <mailto:markb@textmatters.com> | +44 (0)118 986 8313
> http://www.textmatters.com <http://www.textmatters.com/> | Twitter @mark_barratt | Skype mark_barratt
> 
> 
>  

--
Mark Barratt
Text Matters

We help explain things using design | language | systems | process improvement

markb@textmatters.com | +44 (0)118 986 8313
http://www.textmatters.com | Twitter @mark_barratt | Skype mark_barratt