BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
RandyHerbison
Calcite | Level 5

I'm trying to better understand what the PROC REPORT CAPTION option does. If I'm reading the documentation correctly, it says when used with the ACCESSIBLETABLE system option, it makes table captions both visible and accessible.  When used with the NOACCESSIBLE system option, table captions are not displayed but the text is still accessible.  

 

When I use the ACCESSIBLETABLE system option, I see the caption text in P tags just above the TABLE tags.  Shouldn't these be CAPTION tags immediately below the TABLE tags?  Do the CAPTION and ACCESSIBLETABLE options do more than add P tags for the caption text? 

 

Thanks

 

1 ACCEPTED SOLUTION

Accepted Solutions
gdkraus
SAS Employee

Yes, in my opinion, having a double announcement when reading the document linearly (once for the visible caption and once for the table summary) outweighs trying to make a single announcement. This makes the document far more usable for people reading it with screen reading software since there is not a way to make a single announcement and keep the feature of tables being automatically announced with their "summary" attribute.

 

In an ideal world, screen reading software would automatically announce the PDF <caption> tag when they encounter a table, but since they don't do that I recommend using the summary attribute for this information.

 

If you want to add a little more semantic structure to the document for the visible caption, if it is appropriate, you could make them heading levels. That way the screen reader user would hear something like "heading level 4, table foo" then "table foo" when they encounter the table. This step is not required, and might not even be appropriate in all cases, but is simply a suggestion.

View solution in original post

4 REPLIES 4
gdkraus
SAS Employee

There are a couple of things to keep in mind with tables, captions, and PDF.

  • The CONTENTS argument will always be used to populate the "summary" attribute of the table. The summary attribute is not visible within the document, it is only available to screen reading software. The summary is important for screen reading software, because when a user navigates the document table by table (pressing the "t" key), the "summary" is announced like it is a label for the table. This way the user has some idea of what the table is they are about to start reading.
  • The CAPTION argument places a piece of text within the document just above the table to provide a visible label. It is not semantically related to the actual table in any way, other than by proximity. It is a tool to simply place a visible heading above the table. This feature only works when you set ACCESSIBLETABLE. Also, there are no options to change the location of this placement.
  • There is a <caption> tag in PDF, however, while it provides a nice clean tagging structure, functionally it is far less useful than using the "summary" attribute above, because screen reading software does not treat a <caption> any different than a plain <p> in PDF documents. That is why the caption is not tagged as an actual <caption>.

Putting all of this together, if you want a "caption" placed below the table, you can set CONTENTS to be what should be announced when a screen reader lands on the table, and then make a plain <p> below the table to be your visual caption.

 

The usefulness of the CAPTION feature is more apparent in the HTML5 destination. In the HTML5 destination:

  • All tables will always have a <caption> defined, but they can be set to be visible to everyone or only to screen reading software. <caption> acts as the label for the table, like the summary attribute in PDF
  • The HTML5 <caption> will only be visible on the screen when ACCESSIBLETABLE is on.
  • When ACCESSIBLETABLE is on, if the CAPTION is defined, that becomes the <caption>. If only the CONTENTS is defined, that becomes the <caption>

Because of this behavior, an existing SAS application can now have table <caption> elements become visible by adding ACCESSIBLETABLE without having to explicitly define a CAPTION. In HTML5 the position of the <caption> can be controlled with CSS and other techniques. This also keeps the CAPTION and SUMMARY independent of each other in case you need to use them for different purposes.

RandyHerbison
Calcite | Level 5

Thanks for explaining the differences between captions and summaries in HTML5 and PDF.  

 

I'm working on a report that can include from 2 to more than 100 tables each representing a single group.  The number of rows per group/table can vary from a few to hundreds.  All tables share the same simple structure.  Each table requires a visible label/title with the name of the group.  I would like a screen reader to announce the group name when in table navigation mode.  Since the visible label/title will be the same as the summary, depending on how the report is navigated, there is a chance that the same text might be announced twice.  Will the advantages of table summaries outweigh potential disadvantages of redundant text?

 

Thanks 

gdkraus
SAS Employee

Yes, in my opinion, having a double announcement when reading the document linearly (once for the visible caption and once for the table summary) outweighs trying to make a single announcement. This makes the document far more usable for people reading it with screen reading software since there is not a way to make a single announcement and keep the feature of tables being automatically announced with their "summary" attribute.

 

In an ideal world, screen reading software would automatically announce the PDF <caption> tag when they encounter a table, but since they don't do that I recommend using the summary attribute for this information.

 

If you want to add a little more semantic structure to the document for the visible caption, if it is appropriate, you could make them heading levels. That way the screen reader user would hear something like "heading level 4, table foo" then "table foo" when they encounter the table. This step is not required, and might not even be appropriate in all cases, but is simply a suggestion.

RandyHerbison
Calcite | Level 5
Thanks again!