Re: HTML5 DL Element vs. WCAG 2.0 Success Criteria

>> First, because we don't yet have software that can do a great tagging job auto-magically.
> 
> Agreed, but this is the same for sighted users and for blind users…

It's cleaning up after the automation that worries me. The better the automation, the less need for cleanup. Cleanup is the issue because it's the most complex, interactively, of the associated tasks. Good automation reduces the workload for all users, but the impact for AT users would be disproportionally beneficial if (for example) the automation didn't routinely mistake tables for figures <cough>.

>> Second, because the process of fixing accessibility features in PDF is akin to
> > the process of writing alternative text. In other words, it's damned
> > hard to do unless you can fully perceive the thing you are describing.
> 
> As far as I know there are no tools to create PDF files in an accessible way, but they do exist many tools to create web pages in an accessible way, including Notepad.

Just to take one example, OpenOffice (free) creates well-tagged PDF files if (and only if) the source file was properly structured in OpenOffice.

> While the problems regarding the "perception" are exactly the same, the accessibility of the tool is the key factor.

It's a key factor, absolutely.

> I think you are asuuming that the blind user doesn't know in advance what the content is.

I'm assuming that PDF files may contain arbitrary content. In PDF, "arbitrary" can get pretty crazy, especially since PDF files are organized around the mission of rendering a physical page.

> Maybe the user is just repairing a PDF created from a Word document that he has created, in which the user has included images which he knows, tables with structures and data that he already knows, headings for content that he has created…

Improving the accessibility of the available tools will help more users to improve their files - no question about it.

> Indeed, you are asumming that the user is a blind user, but he can have any other disability that implies using a keyboard or a voice recognition system, for example.

Sure, but if the disconnect between the content and the tags is sufficiently great - which is entirely feasible in a PDF created in an application that has no awareness of tagged PDF - lots of tools won't have useful ways to even present the situation, much less deal with it. 

I picked the example of a table because it's a case where the content stream can, for various reasons, become hopelessly tangled with the logical (cellular) structure of the table. Identifying and then grouping graphics objects together within a single Figure tag is another such case. In such cases it's hard to imagine how to solve the problem without detailed mouse-work, irrespective of other factors.

Duff.

Received on Friday, 14 February 2014 23:51:58 UTC