WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Invisible empty Images in accessible PDF - bug? fix? A couple guesses for you to try.

for

From: Christine Hogenkamp
Date: Apr 30, 2020 3:07PM

Hi Phil,

Thanks so much for your suggestions! I had totally forgotten about the
Content panel for some reason, and I was able to delete these Images in the
Content panel, which worked perfectly and allowed the doc to pass the
accessibility check. So thanks again for your help!

Incidentally, looking at these images in the Content panel allowed me to
actually see their outline, it appears that they were a pixel-thin slice of
the image from the previous page (which was full size on the previous page
and arranged right up to the middle edge of the spread between the two
pages) on the edge of the second page, despite the fact that in InDesign
the image does not go over the border between the two pages. Not sure if
there's a way to prevent it (possibly somehow happening in the export to
PDF process?) but at least I can see that's what they are and delete them.

I did also check for empty Figure tags in the Tags panel but, for whatever
reason, when the big image was "split" the Figure tag was kept but the alt
text lost, really strange, and it definitely doesn't show as a Figure in
the Tags panel tree/list of tags, only in the Content panel marked as a
Figure.


*===*
*Christine Hogenkamp*
Front-end Developer

CONTEXT CREATIVE
317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
<https://maps.google.com/?q=317+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>


On Thu, Apr 30, 2020 at 2:04 PM < <EMAIL REMOVED> >
wrote:

>
> ---------- Forwarded message ----------
> From: Philip Kiff < <EMAIL REMOVED> >
> To: <EMAIL REMOVED>
> Cc:
> Bcc:
> Date: Wed, 29 Apr 2020 17:07:50 -0400
> Subject: Re: [WebAIM] Invisible empty Images in accessible PDF - bug? fix?
> A couple guesses for you to try.
>
> Have you tried to find the objects in the "Content" panel? If you open
> up the content tree for Page 1, you might be able to find the objects by
> uising your cursor to manually navigate down all the individual content
> items. Warning: if you delete items from the Content panel, then they
> are permanently deleted from the PDF: it isn't like a tag in the tag
> tree which can simply be retagged.
>
> Second guess, is it possible that you have empty "Figure" tags in the
> "Tags" panel? It can sometimes happen that when you delete or move or
> re-tag an object that an empty tag container gets left behind in the Tag
> tree. These ghost tags can cause errors in automated checkers even when
> they contain no content.
>
> Phil.
>
> Philip Kiff
> D4K Communications
>
> On 2020-04-29 14:22, Christine Hogenkamp wrote:
> > Hello everyone,
> >
> > I am working on an accessible PDF that I am creating from an InDesign
> file
> > that was given to me to arrange for proper accessible PDF publishing (ie
> > tagging elements, add alt text, etc) and overall the doc passed the
> Acrobat
> > Full Check except for a few items flagged under "Other elements alt text
> -
> > Failed" which I am not sure if it's a bug or why I can't seem to get it
> > fixed using the normal Acrobat methods.
> >
> > Acrobat is detecting a handful of empty Images without alt text that come
> > first on a few pages that are not present in the InDesign doc (literally
> > does not show in the Layers panel, no stray text boxes/vector, etc), but
> > also can't be visually seen on the page itself when using the Reading
> Order
> > panel (the page numbering starts at 2, and 1 is not visible anywhere).
> When
> > these invisible Images are selected and the right-click option Delete
> > Selected Structure Item is chosen for the Image, nothing happens. They
> > won't let themselves be deleted, which leads me to believe they are a bug
> > of some kind happening when publishing the PDF.
> >
> > Any thoughts or suggestions for a fix? I am prepared to tell the client
> to
> > just ignore them, seeing as the Full Check has other items that we know
> > usually get flagged but are correct in the document, and these empty
> Image
> > elements don't seem to affect screen reader or keyboard navigation, but
> I'd
> > like to know how to prevent this from happening in the future if
> possible.
> >
> > Thanks!
> >
> > *===*
> > *Christine Hogenkamp*
> > Front-end Developer
> >
> > CONTEXT CREATIVE
> > 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
> > <https://maps.google.com/?q=317+ADELAIDE+ST.+W
> .,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
> > > > > > > > >
>
>
>
> ---------- Forwarded message ----------
> From: Philip Kiff < <EMAIL REMOVED> >
> To: <EMAIL REMOVED>
> Cc:
> Bcc:
> Date: Wed, 29 Apr 2020 17:22:04 -0400
> Subject: Re: [WebAIM] Invisible empty Images in accessible PDF - bug? fix?
> Third guess or suggestion - Perhaps the "Other elements alt text -
> Failed" error relates to incorrectly nested alternative text properties?
> I think this error can sometimes appear when a tag (any tag, not just
> Figure tags) has alternative text applied to it, but then also contains
> other, nested tags...or possibly it occurs when a tag with alternative
> text applied is nested within another tag with alternative text?
>
> And in case my earlier note wasn't clear: all of these attempts at PDF
> fixes use Acrobat DC Pro, not InDesign.
>
> Phil.
>
> On 2020-04-29 17:07, Philip Kiff wrote:
> > A couple guesses for you to try.
> >
> > Have you tried to find the objects in the "Content" panel? If you open
> > up the content tree for Page 1, you might be able to find the objects
> > by uising your cursor to manually navigate down all the individual
> > content items. Warning: if you delete items from the Content panel,
> > then they are permanently deleted from the PDF: it isn't like a tag in
> > the tag tree which can simply be retagged.
> >
> > Second guess, is it possible that you have empty "Figure" tags in the
> > "Tags" panel? It can sometimes happen that when you delete or move or
> > re-tag an object that an empty tag container gets left behind in the
> > Tag tree. These ghost tags can cause errors in automated checkers
> > even when they contain no content.
> >
> > Phil.
> >
> > Philip Kiff
> > D4K Communications
> >
> > On 2020-04-29 14:22, Christine Hogenkamp wrote:
> >> Hello everyone,
> >>
> >> I am working on an accessible PDF that I am creating from an InDesign
> >> file
> >> that was given to me to arrange for proper accessible PDF publishing (ie
> >> tagging elements, add alt text, etc) and overall the doc passed the
> >> Acrobat
> >> Full Check except for a few items flagged under "Other elements alt
> >> text -
> >> Failed" which I am not sure if it's a bug or why I can't seem to get it
> >> fixed using the normal Acrobat methods.
> >>
> >> Acrobat is detecting a handful of empty Images without alt text that
> >> come
> >> first on a few pages that are not present in the InDesign doc (literally
> >> does not show in the Layers panel, no stray text boxes/vector, etc), but
> >> also can't be visually seen on the page itself when using the Reading
> >> Order
> >> panel (the page numbering starts at 2, and 1 is not visible
> >> anywhere). When
> >> these invisible Images are selected and the right-click option Delete
> >> Selected Structure Item is chosen for the Image, nothing happens. They
> >> won't let themselves be deleted, which leads me to believe they are a
> >> bug
> >> of some kind happening when publishing the PDF.
> >>
> >> Any thoughts or suggestions for a fix? I am prepared to tell the
> >> client to
> >> just ignore them, seeing as the Full Check has other items that we know
> >> usually get flagged but are correct in the document, and these empty
> >> Image
> >> elements don't seem to affect screen reader or keyboard navigation,
> >> but I'd
> >> like to know how to prevent this from happening in the future if
> >> possible.
> >>
> >> Thanks!
> >>
> >> *===*
> >> *Christine Hogenkamp*
> >> Front-end Developer
> >>
> >> CONTEXT CREATIVE
> >> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
> >> <https://maps.google.com/?q=317+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
>
> >>
> >> > >> > >> > >> > > > > > > > > >
>