<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><pre><br>On Wed Jul 1, 18:47:57 CEST 2015, Hans Hagen wrote:<br>>><i> /Artifact
</i>>><i>    BMC
</i>>><i>    ..
</i>>><i>    EMC
</i>>
>i'll add the simple variant (i see no need to add properties to 
>something that is supposed to be ignored anyway)<br><br>thanks!<br><br><br>>><i> 2.) Images without alternate text:
</i>>
>i'll pass the label to the tag as alt text
>
>\externalfigure[t:/sources/cow.pdf][label=whatever]
<br>Again, thanks!<br><br>>><i> 3.) Tag names of the resulting tag structure:
</i>>><i> Section 14.8.4 of [1] defines standard structure types, <br></i><i>>
</i>>The set of those standard tags is rather limited and imo one of the <br>>craziest things in pdf as we then end up with abuse of those html tags <br>>(and probably endless discussions on what to map onto what). I don't <br>>even have a clue what it would add to the concept either. Reflow is a <br>>braindead thing anyway.<br><br>Indeed, the set of those tags is very limited. Unfortunately, as <br>far as I know, some screen readers (for the visually impaired)<br>use these as navigation aids, i.e. press button "jump to next section",<br>and the reader will look for the next section marked as <Sect> or something.<br><br>Is it difficult to make the mapping user-defineable in the source tex-file? <br>Say, like such a command:<br>\definemapping[<br>  section=Sect,<br>  sectiontitle=H<br>  sectionnumber=H,<br>  ...<br>  tablerow=TR<br>  ...<br>]<br><br>It would then give users the control on what to map onto what, depending<br>on what kind of documents they create.<br><br>>><i> All in all, these seem to be the only issues that prevent accessible PDF<br>></i>><i> documents with context. For those within an organization where<br>></i>><i> accessibility is required legally for all publications, compliance to at<br>></i>><i> least Acrobat Pro's checks is a huge issue. I do not know how difficult<br>></i>><i> these things are to implement in Context (personally I am just lost in<br>></i>><i> the code), but looking at e.g. tex.stackexchange<br>></i>><i> for question related to accessibility, this is indeed a major obstacle<br>></i>><i> for several people.
</i>>
>In fact adding pdf tagging to context was rather easy. Some time was 
>So, it's not that difficult to add features, more a matter of priorities 
>and motivation (apart from the fact that my acrobat is a bit old by now 
>so I cannot really test).<br><br>I can fully understand that such things are not of the highest priority. <br>Nevertheless accessibility plays more and more a role, e.g. lately, even<br>conferences like <a href="http://chi2015.acm.org/authors/guide-to-an-accessible-submission/" target="_blank">http://chi2015.acm.org/authors/guide-to-an-accessible-submission/</a><br>require accessible pdfs (the workflow they suggest, i.e. tagging a pdf<br>by acrobat pro after compiling of course doesn't work at all - the generated<br>structure is useless).<br><br>Hence, for some users, it makes all the difference. For example for me and<br>some other friends, it would allow to change from using Microsoft Word to <br>a ConTeXt based workflow. <br><br>cheers<br><br>- Dominik<br><span class="st"><em></em></span></pre>                                      </div></body>
</html>