WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: A case for artifacting bullets in unordered lists in PDFs

for

Number of posts in this thread: 19 (In chronological order)

From: Jonathan Metz
Date: Tue, Jul 23 2013 8:21AM
Subject: A case for artifacting bullets in unordered lists in PDFs
No previous message | Next message →

Hi,

Currently I¹m working with someone who insists that unordered lists should
have a <Lbl> in the tag tree if there is a graphic or glyph representing
the Œbullet¹ character. My approach to unordered lists in PDFs is to
artifact the bullet character. The only places I can back up this idea is
from brief mention from CommonLook
(http://www.commonlook.com/docs-commonlook-pdf-lists#lbl) that directs "If
the bullet character itself provides no additional meaning, bullets in
unordered lists should be marked as artifacts,² and the PDF/UA Technical
Implementation Guide
(http://www.aiim.org/Research-and-Publications/standards/committees/PDFUA/T
echnical-Implementation-Guide) under 7.6 Lists, ³In such cases the
graphics objects representing the list's labels should not be contained in
the logical structure and should be marked as Artifacts.²

This is all well and good, but it doesn¹t answer my client¹s complaint
that if JAWS comes across a bulleted list, it¹s difficult to differentiate
the different List Item elements on the page. Is there a way that AT is
'supposed' to interpret unordered lists? If we go with my preference, how
does the average AT user typically acknowledge separate list item elements
on a page? The problem is, while it would be great to have every PDF we
make conform to ISO 14289; technically they only need to conform to
Section 508. Worse, the only reference to handling lists from WCAG (which
Section 508 Refresh is essentially going to mirror) can be found at
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/PDF21.

This page has the worst recommendation for creating lists. First it
suggests that using the list button on the ribbon as the "easiest way to
ensure that lists are formatted correctly when they are converted to PDF².
It doesn¹t actually, since it throws the label element in with the <Lbody>
whenever one exports a list from Word. The user always has to edit those
elements in the tag tree later. It even goes so far as to show screenshots
of what happens when you do that. The worst part of this Œtechnique¹ is
that it mentions the List Elements, but completely fails to explain what
to do with any of them.

Any way, any help would be greatly appreciated.

Jonathan

From: Priti Rohra
Date: Tue, Jul 23 2013 8:40AM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Hi,

As a screenreader user i need bullets to differentiate between list
items of an unordered list.

As an a11y consultant, i'll recommend to add actual text (bullet)
within the lbl tag to inform jaws to read the same.

HTH.

Regards,
Priti.



On 7/23/13, Jonathan Metz < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
>
> Currently I¹m working with someone who insists that unordered lists should
> have a <Lbl> in the tag tree if there is a graphic or glyph representing
> the Œbullet¹ character. My approach to unordered lists in PDFs is to
> artifact the bullet character. The only places I can back up this idea is
> from brief mention from CommonLook
> (http://www.commonlook.com/docs-commonlook-pdf-lists#lbl) that directs "If
> the bullet character itself provides no additional meaning, bullets in
> unordered lists should be marked as artifacts,² and the PDF/UA Technical
> Implementation Guide
> (http://www.aiim.org/Research-and-Publications/standards/committees/PDFUA/T
> echnical-Implementation-Guide) under 7.6 Lists, ³In such cases the
> graphics objects representing the list's labels should not be contained in
> the logical structure and should be marked as Artifacts.²
>
> This is all well and good, but it doesn¹t answer my client¹s complaint
> that if JAWS comes across a bulleted list, it¹s difficult to differentiate
> the different List Item elements on the page. Is there a way that AT is
> 'supposed' to interpret unordered lists? If we go with my preference, how
> does the average AT user typically acknowledge separate list item elements
> on a page? The problem is, while it would be great to have every PDF we
> make conform to ISO 14289; technically they only need to conform to
> Section 508. Worse, the only reference to handling lists from WCAG (which
> Section 508 Refresh is essentially going to mirror) can be found at
> http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/PDF21.
>
> This page has the worst recommendation for creating lists. First it
> suggests that using the list button on the ribbon as the "easiest way to
> ensure that lists are formatted correctly when they are converted to PDF².
> It doesn¹t actually, since it throws the label element in with the <Lbody>
> whenever one exports a list from Word. The user always has to edit those
> elements in the tag tree later. It even goes so far as to show screenshots
> of what happens when you do that. The worst part of this Œtechnique¹ is
> that it mentions the List Elements, but completely fails to explain what
> to do with any of them.
>
> Any way, any help would be greatly appreciated.
>
> Jonathan
>
>
>
>
> > > >

From: McMorland, Gabriel
Date: Tue, Jul 23 2013 8:45AM
Subject: Re: A case for artifacting bullets in unordered lists inPDFs
← Previous message | Next message →

I strongly agree with Priti. I am a blind screen reader user and the bullets are helpful. They convey meaning.
I like Priti's suggestion for labeling bullets so they don't just read as "graphic" when the screen reader encoutners them.

From: Jonathan Metz
Date: Tue, Jul 23 2013 8:52AM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Hmm, interesting.

How do you interpret lists in PDFs that are not bulleted or numbered
lists, say a dictionary list.

What would happen if AT all of a sudden changed the way it handles
unordered lists in the future? Wouldn’t that workaround create a problem
in the future?

Thanks for your input!

Jon

From: Olaf Drümmer
Date: Tue, Jul 23 2013 9:20AM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Hi Jonathan,

Am 23 Jul 2013 um 16:21 schrieb Jonathan Metz < = EMAIL ADDRESS REMOVED = >:

> Currently I¹m working with someone who insists that unordered lists should
> have a <Lbl> in the tag tree if there is a graphic or glyph representing
> the 'bullet' character. My approach to unordered lists in PDFs is to
> artifact the bullet character.

my take:

- characters used for bullets in bulleted lists (from my point of view) are not an accidental by-product of doing page layout / pagination (they exist also on web pages, where no such layout / pagination happens)
- by definition this implies that they cannot be artifacted just because they happen to be in front of list items
- so if they are present, and as they might convey information, they have to be made accessible
- PDF and PDF/UA require that such bullet character is put inside a <Lbl> tag
- in most documents the bullet character is a well defined character (the usual bullet character comes with a Unicode code point, U+2022, and that code point is not in the private use area); thus nothing extra (like applying an ActualText attribute) has to be done in such cases as the character can be pronounced as "bullet" by a screen reader (or the respective word in other languages)
- there might be cases where the bullet point is something other than the usual bullet character; as long as that other character has a well defined Unicode code point outside the private use area, all is fine, no extra work necessary (you can actually check this if you use callas pdfGoHTML: if the bullet character looks the same as in PDF, the Unicode code point seems to work OK, if you see replacement characters, usually empty square characters, it is probably using a private use area code point (private use area - PUA - means that no predefined meaning is associated with code points in this PUA area), and in this case some extra work is necessary (see next list item [pun intended ;-) ]).
- in some cases pictorials are used (or characters without well defined Unicode code point, or a Unicode code point from the private use area) - either a piece of vector graphic, an image, a non-Unicode character, or whatever: in such cases, one may have to use the ActualText (if the content of these pictorials is more like text, or maybe a bullet point drawn in a fancy or multi-colored way, but still looking like a bullet point) or Alt attribute (if the pictorials are more like images) on the content inside the Lbl (not on the Lbl, please).

It will be up to assistive technology (AT) how to present the contents of the Lbl tag. I can understand why some users would want to turn off (at least some of the time) reading out / displaying the Lbl - but it must be possible, if configured accordingly, that access to Lbl is provided.

HTH.

Olaf

From: Sailesh Panchang
Date: Tue, Jul 23 2013 9:34AM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

My understanding is that tagging the bullet as li_label and the text
of the list item as li_title gets JAWS to announce the bullet as a
bullet.
In an ordered list the number is tagged as the label.
Sailesh

On 7/23/13, Jonathan Metz < = EMAIL ADDRESS REMOVED = > wrote:
> Hmm, interesting.
>
> How do you interpret lists in PDFs that are not bulleted or numbered
> lists, say a dictionary list.
>
> What would happen if AT all of a sudden changed the way it handles
> unordered lists in the future? Wouldn’t that workaround create a problem
> in the future?
>
> Thanks for your input!
>
> Jon
>
>
>
>
>
>
> On 7/23/13 10:45 AM, "McMorland, Gabriel" < = EMAIL ADDRESS REMOVED = > wrote:
>
>>I strongly agree with Priti. I am a blind screen reader user and the
>>bullets are helpful. They convey meaning.
>>I like Priti's suggestion for labeling bullets so they don't just read as
>>"graphic" when the screen reader encoutners them.
>>
>>-----Original Message-----
>>From: = EMAIL ADDRESS REMOVED =
>>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Priti Rohra
>>Sent: Tuesday, July 23, 2013 10:40 AM
>>To: WebAIM Discussion List
>>Subject: Re: [WebAIM] A case for artifacting bullets in unordered lists
>>in PDFs
>>
>>Hi,
>>
>>As a screenreader user i need bullets to differentiate between list
>>items of an unordered list.
>>
>>As an a11y consultant, i'll recommend to add actual text (bullet) within
>>the lbl tag to inform jaws to read the same.
>>
>>HTH.
>>
>>Regards,
>>Priti.
>>
>>
>>
>>On 7/23/13, Jonathan Metz < = EMAIL ADDRESS REMOVED = > wrote:
>>> Hi,
>>>
>>> Currently I¹m working with someone who insists that unordered lists
>>> should have a <Lbl> in the tag tree if there is a graphic or glyph
>>> representing the Œbullet¹ character. My approach to unordered lists in
>>> PDFs is to artifact the bullet character. The only places I can back
>>> up this idea is from brief mention from CommonLook
>>> (http://www.commonlook.com/docs-commonlook-pdf-lists#lbl) that directs
>>> "If the bullet character itself provides no additional meaning,
>>> bullets in unordered lists should be marked as artifacts,² and the
>>> PDF/UA Technical Implementation Guide
>>> (http://www.aiim.org/Research-and-Publications/standards/committees/PD
>>> FUA/T
>>> echnical-Implementation-Guide) under 7.6 Lists, ³In such cases the
>>> graphics objects representing the list's labels should not be
>>> contained in the logical structure and should be marked as Artifacts.²
>>>
>>> This is all well and good, but it doesn¹t answer my client¹s complaint
>>> that if JAWS comes across a bulleted list, it¹s difficult to
>>> differentiate the different List Item elements on the page. Is there a
>>> way that AT is 'supposed' to interpret unordered lists? If we go with
>>> my preference, how does the average AT user typically acknowledge
>>> separate list item elements on a page? The problem is, while it would
>>> be great to have every PDF we make conform to ISO 14289; technically
>>> they only need to conform to Section 508. Worse, the only reference to
>>> handling lists from WCAG (which Section 508 Refresh is essentially
>>> going to mirror) can be found at
>>>http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/PDF21.
>>>
>>> This page has the worst recommendation for creating lists. First it
>>> suggests that using the list button on the ribbon as the "easiest way
>>> to ensure that lists are formatted correctly when they are converted to
>>>PDF².
>>> It doesn¹t actually, since it throws the label element in with the
>>> <Lbody> whenever one exports a list from Word. The user always has to
>>> edit those elements in the tag tree later. It even goes so far as to
>>> show screenshots of what happens when you do that. The worst part of
>>> this Œtechnique¹ is that it mentions the List Elements, but completely
>>> fails to explain what to do with any of them.
>>>
>>> Any way, any help would be greatly appreciated.
>>>
>>> Jonathan
>>>
>>>
>>>
>>>
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>>
>>>>>>messages to = EMAIL ADDRESS REMOVED =
>>>>>>>
> > > >

From: Jonathan Metz
Date: Tue, Jul 23 2013 10:59AM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Hi Olaf,

Thanks for responding.

>-characters used for bullets in bulleted lists (from my point of view)
>are not an accidental by-product of doing page layout / pagination (they
>exist also
>-on web pages, where no such layout / pagination happens)
>-by definition this implies that they cannot be artifacted just because
>they happen to be in front of list items


My reasoning comes from a discussion I had a while ago on LinkedIn about
what to do with custom bullets in Links. It was suggested that if they
provided no semantic meaning, Bullets should be hidden from screen
readers. I guess the school of thought being that if it had numbers, it
would be more important to listen to them. But I see yours (and others)
point about how creating a Bullet for a list creates semantic context for
what kind of list it is.

>
>- PDF and PDF/UA require that such bullet character is put inside a <Lbl>
>tag

The problem is, PDF 1.7 never explicitly states that a <Lbl> tag is
mandatory. The only language it provides is through the ‘ListNumbering’
attribute (under Table 347), which says "Lbl elements (if present) contain
arbitrary text not subject to any numbering scheme”. I understand that
ListNumbering is about what kind of L it is, but this was the only
indication I could find where 32000 mentions the Lbl’s presence. Why would
it mention ‘If Present’ if it couldn’t possibly also be ‘Not Present’?
Could I use the ListNumbering to specify this is an unordered list instead
in previous documents? Where would that have gone? I digress...


ISO 14289 only states "Lbl and LBody tags may be included”. The Tech Imp
guide mentions that these things should be hidden from view.

Whatever, I see your points and will change my recommendation regarding
Bullets in PDFs.


>- on the content inside the Lbl (not on the Lbl, please).



If I change the properties in a content box, it affects the tag it resides
in. Should I nest these inside <Span> then?

Again, thanks for the advice. I’ll suggest otherwise from now on since I
have real world examples of a request for bullets in a list. If there is a
list without bullets, how would I provide the ListNumbering Attribute?

Thanks!
Jon

From: McMorland, Gabriel
Date: Tue, Jul 23 2013 11:05AM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

bullets in lists tell readers where one list item ends and another begins. This is very important semantic information for screen reader users who cannot rely on visual layout. Or spacing.
I can't think of an example where it wouldn't be helpful to have bullets included.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jonathan Metz
Sent: Tuesday, July 23, 2013 12:59 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] A case for artifacting bullets in unordered lists in PDFs

Hi Olaf,

Thanks for responding.

>-characters used for bullets in bulleted lists (from my point of view)
>are not an accidental by-product of doing page layout / pagination
>(they exist also -on web pages, where no such layout / pagination
>happens) -by definition this implies that they cannot be artifacted
>just because they happen to be in front of list items


My reasoning comes from a discussion I had a while ago on LinkedIn about what to do with custom bullets in Links. It was suggested that if they provided no semantic meaning, Bullets should be hidden from screen readers. I guess the school of thought being that if it had numbers, it would be more important to listen to them. But I see yours (and others) point about how creating a Bullet for a list creates semantic context for what kind of list it is.

>
>- PDF and PDF/UA require that such bullet character is put inside a
><Lbl> tag

The problem is, PDF 1.7 never explicitly states that a <Lbl> tag is mandatory. The only language it provides is through the 'ListNumbering'
attribute (under Table 347), which says "Lbl elements (if present) contain arbitrary text not subject to any numbering scheme". I understand that ListNumbering is about what kind of L it is, but this was the only indication I could find where 32000 mentions the Lbl's presence. Why would it mention 'If Present' if it couldn't possibly also be 'Not Present'?
Could I use the ListNumbering to specify this is an unordered list instead in previous documents? Where would that have gone? I digress...


ISO 14289 only states "Lbl and LBody tags may be included". The Tech Imp guide mentions that these things should be hidden from view.

Whatever, I see your points and will change my recommendation regarding Bullets in PDFs.


>- on the content inside the Lbl (not on the Lbl, please).



If I change the properties in a content box, it affects the tag it resides in. Should I nest these inside <Span> then?

Again, thanks for the advice. I'll suggest otherwise from now on since I have real world examples of a request for bullets in a list. If there is a list without bullets, how would I provide the ListNumbering Attribute?

Thanks!
Jon




On 7/23/13 11:20 AM, "Olaf Drümmer" < = EMAIL ADDRESS REMOVED = > wrote:

>Hi Jonathan,
>
>Am 23 Jul 2013 um 16:21 schrieb Jonathan Metz
>< = EMAIL ADDRESS REMOVED = >:
>
>> Currently I¹m working with someone who insists that unordered lists
>>should have a <Lbl> in the tag tree if there is a graphic or glyph
>>representing the 'bullet' character. My approach to unordered lists
>>in PDFs is to artifact the bullet character.
>
>my take:
>
>- characters used for bullets in bulleted lists (from my point of view)
>are not an accidental by-product of doing page layout / pagination
>(they exist also on web pages, where no such layout / pagination
>happens)
>- by definition this implies that they cannot be artifacted just
>because they happen to be in front of list items
>- so if they are present, and as they might convey information, they
>have to be made accessible

>- PDF and PDF/UA require that such bullet character is put inside a
><Lbl> tag

>- in most documents the bullet character is a well defined character
>(the usual bullet character comes with a Unicode code point, U+2022,
>and that code point is not in the private use area); thus nothing extra
>(like applying an ActualText attribute) has to be done in such cases as
>the character can be pronounced as "bullet" by a screen reader (or the
>respective word in other languages)
>- there might be cases where the bullet point is something other than
>the usual bullet character; as long as that other character has a well
>defined Unicode code point outside the private use area, all is fine,
>no extra work necessary (you can actually check this if you use callas
>pdfGoHTML: if the bullet character looks the same as in PDF, the
>Unicode code point seems to work OK, if you see replacement characters,
>usually empty square characters, it is probably using a private use
>area code point (private use area - PUA - means that no predefined
>meaning is associated with code points in this PUA area), and in this
>case some extra work is necessary (see next list item [pun intended ;-) ]).
>- in some cases pictorials are used (or characters without well defined
>Unicode code point, or a Unicode code point from the private use area)
>- either a piece of vector graphic, an image, a non-Unicode character,
>or
>whatever: in such cases, one may have to use the ActualText (if the
>content of these pictorials is more like text, or maybe a bullet point
>drawn in a fancy or multi-colored way, but still looking like a bullet
>point) or Alt attribute (if the pictorials are more like images) on
>the content inside the Lbl (not on the Lbl, please).
>
>It will be up to assistive technology (AT) how to present the contents
>of the Lbl tag. I can understand why some users would want to turn off
>(at least some of the time) reading out / displaying the Lbl - but it
>must be possible, if configured accordingly, that access to Lbl is provided.
>
>HTH.
>
>Olaf
>
>
>>>messages to = EMAIL ADDRESS REMOVED =

From: Andrew Kirkpatrick
Date: Tue, Jul 23 2013 2:21PM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Some comments inline:

Currently I¹m working with someone who insists that unordered lists should have a <Lbl> in the tag tree if there is a graphic or glyph representing the Œbullet¹ character. My approach to unordered lists in PDFs is to artifact the bullet character.

[AWK] Lbl is optional, per the ISO 32000 and ISO 14289 specs. Not a bad idea, but optional. I would disagree that artifacting the bullet character is helpful. Most AT recognize the bullet character and announce "bullet" so you don't need to use ActualText unless you are using a non-standard bullet (e.g. using a star for the bullet). As far as how the information is conveyed to AT if you use Lbl and Lbody, just Lbody, or even just put the text inside the LI directly - it is the same. The only difference with JAWS is that when you use Lbl the bullet is being read as if it is on its own line, which in my mind isn't a great way of announcing the bullet item.

This is all well and good, but it doesn¹t answer my client¹s complaint that if JAWS comes across a bulleted list, it¹s difficult to differentiate the different List Item elements on the page. Is there a way that AT is 'supposed' to interpret unordered lists? If we go with my preference, how does the average AT user typically acknowledge separate list item elements on a page? The problem is, while it would be great to have every PDF we make conform to ISO 14289; technically they only need to conform to Section 508. Worse, the only reference to handling lists from WCAG (which Section 508 Refresh is essentially going to mirror) can be found at http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/PDF21.

[AWK] screen readers are provided with information that a list is present, how many list items there are, and what list nesting level the list is at. JAWS allows users to jump from list to list and from list item to item with quickkeys, although some users will read the list with the arrow keys. There is no doubt that the bullet or the number helps differentiate for the user when they are on a new bullet in this case, but the AT does provide additional tools.

This page has the worst recommendation for creating lists. First it suggests that using the list button on the ribbon as the "easiest way to ensure that lists are formatted correctly when they are converted to PDF².
It doesn¹t actually, since it throws the label element in with the <Lbody> whenever one exports a list from Word. The user always has to edit those elements in the tag tree later. It even goes so far as to show screenshots of what happens when you do that. The worst part of this Œtechnique¹ is that it mentions the List Elements, but completely fails to explain what to do with any of them.

[AWK] The context of the paragraph is making a list in Word and converting it to PDF. Can you advise on a better or easier way to accomplish this within Word? The lists are correctly formatted when created from Word in this way, although it is not the only way for a list to be correctly formatted. There is no need to change these lists in Acrobat later to add the Lbl tag, unless it just makes you happy to see the full form of the allowable list structure in the tags.

From: Jonathan Metz
Date: Tue, Jul 23 2013 2:47PM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Hello Andrew!

I’ve already told my client to ignore the previous suggestions about
artifacting labels because it is apparently more accessible to leave them
in there. I guess I just needed proof that real-world examples existed,
and since they do, there is not much point in directing others to do
otherwise.



[AWK] The context of the paragraph is making a list in Word and converting
it to PDF. Can you advise on a better or easier way to accomplish this
within Word? The lists are correctly formatted when created from Word in
this way, although it is not the only way for a list to be correctly
formatted.

Sure. I’ll tell you the same suggestion I made to WCAG (thanks, btw for
that link you provided to Olaf earlier).

I would argue that a better phrase would be that “using the list button in
the Ribbon provides a relatively decent basis or foundation for proper
list structure, but users should expect to perform further work in
Acrobat."


[AWK] There is no need to change these lists in Acrobat later to add the
Lbl tag, unless it just makes you happy to see the full form of the
allowable list structure in the tags.

Actually, if a user wants to ensure that they are following specification,
they do. ISO 32000 Table 336 states "(Label) A name or number that
distinguishes a given item from others in the same list or other group of
like items. NOTE: In a dictionary list, for example, it contains the term
being defined; in a bulleted or numbered list, it contains the bullet
character or the number of the list item and associated punctuation.”

Placing the bullet or number in the LBody tag is incorrect (LBody,
according to 32000 Table 336, is "The descriptive content of a list
item.”). Further, use of the ListNumbering attribute, as required by ISO
14289 states that it is "The numbering system used to generate the content
of the Lbl (Label) elements in an autonumbered list, or the symbol used to
identify each item in an unnumbered list.” If the Lbl tag is omitted, then
how does the ListNumbering system supposed to work?

So if a user should not artifact bullets yet should NOT put the bullet in
the Lbl tag, where would one put that if there was no need to add a Lbl
tag.

Thanks again for your comments and suggestions,
Jonathan

From: Olaf Drümmer
Date: Tue, Jul 23 2013 3:10PM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Hi Jonathan,

>>
>> - PDF and PDF/UA require that such bullet character is put inside a <Lbl>
>> tag
>
> The problem is, PDF 1.7 never explicitly states that a <Lbl> tag is
> mandatory.

PDF 1.7 describes syntax and how to use it for a certain purpose. It very clearly states that something that is a 'label' (bullet, number for a list item, term to be defined for a dictionary list, …) is put inside a Lbl tag.

Admittedly PDF 1.7 is not using strong normative language. But by ignoring the statement that labels go inside a Lbl tag, one is simply not following the rules of the syntax.

PDF/UA uses stronger normative language by stating that one must always use tags, and that one must use the right tags:

Excerpt from ISO 1428901, 7.1:
> "Content shall be marked in the structure tree with semantically appropriate tags …. "


> The only language it provides is through the ‘ListNumbering’
> attribute (under Table 347), which says "Lbl elements (if present) contain
> arbitrary text not subject to any numbering scheme”. I understand that
> ListNumbering is about what kind of L it is, but this was the only
> indication I could find where 32000 mentions the Lbl’s presence. Why would
> it mention ‘If Present’ if it couldn’t possibly also be ‘Not Present’?

you can easily have lists without a label character in from of the list items.

> Could I use the ListNumbering to specify this is an unordered list instead
> in previous documents? Where would that have gone? I digress…

that's what the None value is for:

Excerpt from ISO 32000-1 (PDF 1.7), 14.8.5.5, Table 347
> None: No autonumbering; Lbl elements (if present) contain arbitrary text not subject to any numbering scheme


> ISO 14289 only states "Lbl and LBody tags may be included”.

it's kind of just repeating ISO 320001- here:

Excerpt from ISO 32000-1 (PDF 1.7), 14.8.4.3.3, Table 336
> (List item) An individual member of a list. Its children may be one or more labels, list bodies, or both (structure types Lbl or LBody).

the idea here is to keep things very open; who says the list item label must always be in front of the list item? Maybe in some fancy list it's in the middle of list items, and some list item body before and after. Naybe it has label in front and after each list item? And maybe there is no label at all because the list appearance is created by some other visual mechanism, like a box around each list item

> The Tech Imp
> guide mentions that these things should be hidden from view.

where does it say so? I must be missing something.

>> - on the content inside the Lbl (not on the Lbl, please).
>
> If I change the properties in a content box, it affects the tag it resides
> in. Should I nest these inside <Span> then?

I believe this would be the right approach



Thanks,

Olaf

From: Jonathan Metz
Date: Tue, Jul 23 2013 3:31PM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

>> you can easily have lists without a label character in from of the list
>>items.


[Me] Hi Olaf. I¹m having difficulty understanding you here. Can you
extrapolate this for me?



>[Me]ISO 14289 only states "Lbl and LBody tags may be included².

it's kind of just repeating ISO 320001- here:

Excerpt from ISO 32000-1 (PDF 1.7), 14.8.4.3.3, Table 336
>(List item) An individual member of a list. Its children may be one or
>more labels, list bodies, or both (structure types Lbl or LBody).

the idea here is to keep things very open; who says the list item label
must always be in front of the list item? Maybe in some fancy list it's in
the middle of list items, and some list item body before and after. Naybe
it has label in front and after each list item? And maybe there is no
label at all because the list appearance is created by some other visual
mechanism, like a box around each list item

[Me] I wasn¹t trying to imply that there was some fancy order to list
structure, just that ISO 32000 says it *may* include something not *must*
include. ŒMust¹ means a requirement, whereas may implies a suggestion.

OrŠ Are you saying that theoretically it would be fine to have an L tag
and what is inside of it is the bullet and content of the list?


>[Me]The Tech Imp
>guide mentions that these things should be hidden from view.

where does it say so? I must be missing something.

[Me] You must have missed it from the beginning of the email chain:

"In a unordered list without Lbl elements (which is permissible) the value
of ListNumbering should be "None". In such cases the graphics objects
representing the list's labels should not be contained in the logical
structure and should be marked as Artifacts. - See more at:
http://www.aiim.org/Research-and-Publications/standards/committees/PDFUA/Te
chnical-Implementation-Guide#Section7²

Again, thanks for your help,
Jonathan



On 7/23/13 5:10 PM, "Olaf Drümmer" < = EMAIL ADDRESS REMOVED = > wrote:



>Hi Jonathan,
>
>>>
>>> - PDF and PDF/UA require that such bullet character is put inside a
>>><Lbl>
>>> tag
>>
>> The problem is, PDF 1.7 never explicitly states that a <Lbl> tag is
>> mandatory.
>
>PDF 1.7 describes syntax and how to use it for a certain purpose. It very
>clearly states that something that is a 'label' (bullet, number for a
>list item, term to be defined for a dictionary list, Š) is put inside a
>Lbl tag.
>
>Admittedly PDF 1.7 is not using strong normative language. But by
>ignoring the statement that labels go inside a Lbl tag, one is simply not
>following the rules of the syntax.
>
>PDF/UA uses stronger normative language by stating that one must always
>use tags, and that one must use the right tags:
>
>Excerpt from ISO 1428901, 7.1:
>> "Content shall be marked in the structure tree with semantically
>>appropriate tags Š. "
>
>
>> The only language it provides is through the ŒListNumbering¹
>> attribute (under Table 347), which says "Lbl elements (if present)
>>contain
>> arbitrary text not subject to any numbering scheme². I understand that
>> ListNumbering is about what kind of L it is, but this was the only
>> indication I could find where 32000 mentions the Lbl¹s presence. Why
>>would
>> it mention ŒIf Present¹ if it couldn¹t possibly also be ŒNot Present¹?
>
>you can easily have lists without a label character in from of the list
>items.
>
>> Could I use the ListNumbering to specify this is an unordered list
>>instead
>> in previous documents? Where would that have gone? I digressŠ
>
>that's what the None value is for:
>
>Excerpt from ISO 32000-1 (PDF 1.7), 14.8.5.5, Table 347
>> None: No autonumbering; Lbl elements (if present) contain arbitrary
>>text not subject to any numbering scheme
>
>
>> ISO 14289 only states "Lbl and LBody tags may be included².
>
>it's kind of just repeating ISO 320001- here:
>
>Excerpt from ISO 32000-1 (PDF 1.7), 14.8.4.3.3, Table 336
>> (List item) An individual member of a list. Its children may be one or
>>more labels, list bodies, or both (structure types Lbl or LBody).
>
>the idea here is to keep things very open; who says the list item label
>must always be in front of the list item? Maybe in some fancy list it's
>in the middle of list items, and some list item body before and after.
>Naybe it has label in front and after each list item? And maybe there is
>no label at all because the list appearance is created by some other
>visual mechanism, like a box around each list item
>
>> The Tech Imp
>> guide mentions that these things should be hidden from view.
>
>where does it say so? I must be missing something.
>
>>> - on the content inside the Lbl (not on the Lbl, please).
>>
>> If I change the properties in a content box, it affects the tag it
>>resides
>> in. Should I nest these inside <Span> then?
>
>I believe this would be the right approach
>
>
>
>Thanks,
>
>Olaf
>
>>>

From: Olaf Drümmer
Date: Tue, Jul 23 2013 3:34PM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Hi Andrew,

Am 23 Jul 2013 um 22:21 schrieb Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >:

> [AWK] Lbl is optional, per the ISO 32000 and ISO 14289 specs.

they are only optional insofar as if there is no bullet character or other kind of label in the page content, then that's fine, and no Lbl has to be present in the tagging structure for the list. But if there is page content that would be considered a bullet character or other kind of label in front of a list item, then PDF/UA clearly mandates that - for labels in list items as much as any other content - the right tag shall be used - and that would be the Lbl tag. No exceptions.


> [AWK] …. As far as how the information is conveyed to AT if you use Lbl and Lbody, just Lbody, or even just put the text inside the LI directly - it is the same. The only difference with JAWS is that when you use Lbl the bullet is being read as if it is on its own line, which in my mind isn't a great way of announcing the bullet item.

The way you write a statement like this is possibly (as I might be reading too much into it) flawed in two ways:
- it silently equates AT to screenreaders
- it silently equates screenreaders to JAWS
[I do know that you are writing it this way with only the best intentions, but...]

This is a common source for a lot of misinformation and misjudgments. JAWS is just one implementation of one type of AT.

Just to give you an example why always pointing to screen readers for blind and low vision users is problematic:

Envision AT that helps a dyslexic user do two things:
- make reading easier (or possible at all)
- help improve reading skills
There are a couple of ways to do this, for example by enlarging the page view, centering the current content in the document window, highlighting every piece of the content let's say word by word, while dimming everything around it (to reduce distraction by immediate context), speak out loud the word, additionally provide an alternate rendition of the word in a special font, then go on to the next word, etc.. If a person with dyslexia (many of them young people still learning the written language, and some of them overcoming their problems over time by working and learning very hard) never encounters a list label, he/she will not become familiar with the concept of 'list item labels'. Not good.

I could think of various other types of AT where not getting list labels right is just not the right thing to do. If it's there and is content (as opposed to decoration or some pagination side effect not conveying any meaning) - tag it! When tagging, always use the right tag (from the set of standard tags in PDF 1.7)! Not more, not less. Skipping or mis-tagging is bad, even if some groups of users wouldn't mind. At least that's the message of PDF/UA.


Olaf

From: Olaf Drümmer
Date: Tue, Jul 23 2013 3:50PM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Hi Jonathan,

Am 23 Jul 2013 um 23:31 schrieb Jonathan Metz < = EMAIL ADDRESS REMOVED = >:

>>> you can easily have lists without a label character in from of the list
>>> items.
>
>
> [Me] Hi Olaf. I¹m having difficulty understanding you here. Can you
> extrapolate this for me?

I'll simulate one here (the 'lines' are just that indicate lines to be draw as a box, or maybe a pastel colour background rectangle):



Three things you need for a cup of tea:

--------------------------------
| a cup |
--------------------------------

--------------------------------
| tea leaves |
--------------------------------

--------------------------------
| hot water |
--------------------------------



Would you agree there is simply a list with three items? But there is no bullet character or something like that. Lists are lists when they are intended/designed/perceived as lists. There visual cues beyond bullet characters that can make people see/understand they have a list in front of them.


A very typical way to do this is actually on title pages of magazines: they have lists of text that point to the articles, but in many cases they do not use bullet characters. As an example look at the Macworld title page shown at this URL:

http://www.iphoneography.com/journal/2010/7/29/macworld-magazine-cover-shot-on-an-iphone.html

there is a 3 item list under the iPhone 4 tagline - and it uses spacing only, no bullet character or similar.


Olaf

From: Ryan E. Benson
Date: Tue, Jul 23 2013 9:09PM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Andrew (and Olaf),

[AWK]: Most AT recognize the bullet character and announce "bullet" so you
don't need to use ActualText unless you are using a non-standard bullet
(e.g. using a star for the bullet).
[REB]: What should be placed as the value of the actualText if a
non-standard bullet (such as U+25B6 (right facing triangle))? Just bullet?

--
Ryan E. Benson


On Tue, Jul 23, 2013 at 4:21 PM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >wrote:

> Some comments inline:
>
> Currently I¹m working with someone who insists that unordered lists should
> have a <Lbl> in the tag tree if there is a graphic or glyph representing
> the Œbullet¹ character. My approach to unordered lists in PDFs is to
> artifact the bullet character.
>
> [AWK] Lbl is optional, per the ISO 32000 and ISO 14289 specs. Not a bad
> idea, but optional. I would disagree that artifacting the bullet character
> is helpful. Most AT recognize the bullet character and announce "bullet"
> so you don't need to use ActualText unless you are using a non-standard
> bullet (e.g. using a star for the bullet). As far as how the information
> is conveyed to AT if you use Lbl and Lbody, just Lbody, or even just put
> the text inside the LI directly - it is the same. The only difference with
> JAWS is that when you use Lbl the bullet is being read as if it is on its
> own line, which in my mind isn't a great way of announcing the bullet item.
>
> This is all well and good, but it doesn¹t answer my client¹s complaint
> that if JAWS comes across a bulleted list, it¹s difficult to differentiate
> the different List Item elements on the page. Is there a way that AT is
> 'supposed' to interpret unordered lists? If we go with my preference, how
> does the average AT user typically acknowledge separate list item elements
> on a page? The problem is, while it would be great to have every PDF we
> make conform to ISO 14289; technically they only need to conform to Section
> 508. Worse, the only reference to handling lists from WCAG (which Section
> 508 Refresh is essentially going to mirror) can be found at
> http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/PDF21.
>
> [AWK] screen readers are provided with information that a list is present,
> how many list items there are, and what list nesting level the list is at.
> JAWS allows users to jump from list to list and from list item to item
> with quickkeys, although some users will read the list with the arrow keys.
> There is no doubt that the bullet or the number helps differentiate for the
> user when they are on a new bullet in this case, but the AT does provide
> additional tools.
>
> This page has the worst recommendation for creating lists. First it
> suggests that using the list button on the ribbon as the "easiest way to
> ensure that lists are formatted correctly when they are converted to PDF².
> It doesn¹t actually, since it throws the label element in with the <Lbody>
> whenever one exports a list from Word. The user always has to edit those
> elements in the tag tree later. It even goes so far as to show screenshots
> of what happens when you do that. The worst part of this Œtechnique¹ is
> that it mentions the List Elements, but completely fails to explain what to
> do with any of them.
>
> [AWK] The context of the paragraph is making a list in Word and converting
> it to PDF. Can you advise on a better or easier way to accomplish this
> within Word? The lists are correctly formatted when created from Word in
> this way, although it is not the only way for a list to be correctly
> formatted. There is no need to change these lists in Acrobat later to add
> the Lbl tag, unless it just makes you happy to see the full form of the
> allowable list structure in the tags.
>
> > > >

From: Chagnon | PubCom
Date: Tue, Jul 23 2013 11:08PM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

It depends upon the context of the list, but in most cases the actual
character used as the bullet is a decorative piece of frou-frou so
regardless of whether it's a traditional round bullet, square, triangle, or
smiley face, AT users really just need to know it's a bullet.

If we spend too much time on this low-level stuff, we'll never have enough
hours in a day for the major stuff, like writing a good document, designing
it, writing informative alt-text, and tagging it for accessibility.

-Bevi Chagnon
- PubCom.com - Trainers, Consultants, Designers, and Developers.
- Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.

-----Original Message-----
[AWK]: Most AT recognize the bullet character and announce "bullet" so you
don't need to use ActualText unless you are using a non-standard bullet
(e.g. using a star for the bullet).
[REB]: What should be placed as the value of the actualText if a
non-standard bullet (such as U+25B6 (right facing triangle))? Just bullet?

From: Olaf Drümmer
Date: Wed, Jul 24 2013 3:18AM
Subject: Re: A case for artifacting bullets in unordered lists in PDFs
← Previous message | Next message →

Am 24 Jul 2013 um 07:08 schrieb Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >:

> AT users really just need to know it's a bullet.

why would that be? Why discard information that is there already? Would you discard a symbolic characters in the middle of a text?

Am 24 Jul 2013 um 05:09 schrieb Ryan E. Benson < = EMAIL ADDRESS REMOVED = >:

> [REB]: What should be placed as the value of the actualText if a
> non-standard bullet (such as U+25B6 (right facing triangle))? Just bullet?

and

Am 24 Jul 2013 um 07:08 schrieb Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >:

> If we spend too much time on this low-level stuff, we'll never have enough
> hours in a day for the major stuff, like writing a good document, designing
> it, writing informative alt-text, and tagging it for accessibility.

if the label character has a valid Unicode code point (outside of the private use area) - *** no action is required *** - the text is already accessible. It is up to an AT with a text to speech function to read it out loud accordingly. In this case it hopefully would read "right facing triangle"; if an AT developer decides to give a user options, like "turn this off for a while because I can't stand listening to "right facing triangle" more than three times on a given day", that's fine, but that's not anything to do with how the content / document has been prepared.

The easiest way to find whether a bullet has a suitable Unicode code point: copy and paste it into a strictly text only / no formatting text editing window or text field (the "Save as…" field of any application's user interface will do) and look at the appearance of the pasted character: if it still looks the same it has a reliable Unicode code point, if it has a replacement character (empty square, or strange looking face mask, or something like that) it does not have a Unicode code point that will work, and some action should be taken (preferably ActualText, with a suitable replacement text).

Olaf

From: Chagnon | PubCom
Date: Wed, Jul 24 2013 11:09AM
Subject: Re: A case for artifacting bullets in unordered lists inPDFs
← Previous message | Next message →

Olaf, I think you might have misunderstood what I was commenting on.

Olaf asked: "Why discard information that is there already?" In this
situation, nothing is being discarded. The question was whether anything had
to be added, such as Actual Text. The poster had asked, if he used a
different bullet character such as a right-pointing triangle, would he need
to put actual text on it.

Olaf asked: "Would you discard a symbolic characters in the middle of a
text?"
Of course not because that's a different editorial use of the character, not
what's being discussed here. Symbols in the middle of text have editorial
meaning and purpose.

In this case, the bullet character is just a character that doesn't give any
further information than that it signals a new item in a list, a "bullet."
The most critical information is the text content of the list itself, not
the visually decorative character used, such as a square or round bullet.

In fact, a few years back it was proposed on this list that bullet
characters should be artifacted because they are nonessential. And the idea
has resurrected (note the subject of this thread). In the professional
typesetting industry, these characters have been called "dingbats" for well
over a hundred years, so that should be a clue as to their editorial
importance.

There are times where the bullet character does have relevant meaning in the
list — such as the check mark and "x" ballot box characters, or a series of
nested bullets going from solid circle to hollow circle — but for nearly all
lists, the document designer chose a character for the bullet based solely
on visual appearance, not substantive meaning. That's decorative frou-frou,
not substance. Who knew so many people would use the white smiley face
U+263A or black heart U+2665 for bullet characters in professional
documents!

In a perfect world, it's as you described, Olaf:
1) the document (Word, Office, InDesign, PDF, etc.) will tag the list
appropriately.
2) the AT will voice the bullet character correctly, as well as the
structure of the list and list item.
3) the user can control voicing of the character.
4) the character has a valid Unicode code point.
5) the AT can interpret and voice the valid Unicode character.

But the Word document I just reviewed for a client proves that we are far
from utopia. 300+ page government document with "I lost count of how many
but it was over 1,000" bullets. They insist that it be in Word 2003 and that
Acrobat 7 be used for finishing the accessibility.

Documents of that size and nature are often written by several people and
the versions compiled into one final document. So everyone involved had used
a different bullet for "their" bullets: large circles, small circles,
squares, em-dashes, asterisk, and several that came is as white squares
meaning they were nonvalid Unicode characters, so I don't know what they
were supposed to be. This was government statistical data, so the actual
bullet character was irrelevant to the content.

Plus, several lists were incorrectly made with each bulleted item in its own
separate list.

I my staff have only 8-10 hours in a day to remediate documents for
accessibility, and our clients have limited money to pay us to do this work.

What should I spend that time and money doing? What's most beneficial for AT
users? Choose one below because our time and money is limited:

a) Ensure that the various bullet characters are voice correctly, even if
that means manually adding Actual Text one-by-one to non-standard nonvalid
Unicode characters, up to 1,000 times in the document.

b) Edit the document so that it makes logical sense, reduce the number of
lists and bullets into something that makes logical sense, tag the lists
correctly, standardize all the bullet lists so that only one generic round
bullet character is use throughout, and aim for getting a well-tagged PDF in
the end that is useful and easy on the ears for screen reader users.

Remember, this is not a perfect world: we have substantial technology holes
and gaps in the workflow so I won't have "perfect" bullets every time.

Where should my client invest the time and money, a) or b)?

— Bevi Chagnon
— PubCom.com — Trainers, Consultants, Designers, and Developers.
— Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Olaf Drümmer

Am 24 Jul 2013 um 07:08 schrieb Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >:

> AT users really just need to know it's a bullet.

why would that be? Why discard information that is there already? Would you
discard a symbolic characters in the middle of a text?

Am 24 Jul 2013 um 05:09 schrieb Ryan E. Benson < = EMAIL ADDRESS REMOVED = >:

> [REB]: What should be placed as the value of the actualText if a
> non-standard bullet (such as U+25B6 (right facing triangle))? Just bullet?

and

Am 24 Jul 2013 um 07:08 schrieb Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >:

> If we spend too much time on this low-level stuff, we'll never have
> enough hours in a day for the major stuff, like writing a good
> document, designing it, writing informative alt-text, and tagging it for
accessibility.

if the label character has a valid Unicode code point (outside of the
private use area) - *** no action is required *** - the text is already
accessible. It is up to an AT with a text to speech function to read it out
loud accordingly. In this case it hopefully would read "right facing
triangle"; if an AT developer decides to give a user options, like "turn
this off for a while because I can't stand listening to "right facing
triangle" more than three times on a given day", that's fine, but that's not
anything to do with how the content / document has been prepared.

The easiest way to find whether a bullet has a suitable Unicode code point:
copy and paste it into a strictly text only / no formatting text editing
window or text field (the "Save as…" field of any application's user
interface will do) and look at the appearance of the pasted character: if it
still looks the same it has a reliable Unicode code point, if it has a
replacement character (empty square, or strange looking face mask, or
something like that) it does not have a Unicode code point that will work,
and some action should be taken (preferably ActualText, with a suitable
replacement text).

Olaf

From: Andrew Kirkpatrick
Date: Wed, Jul 24 2013 1:03PM
Subject: Re: A case for artifacting bullets in unordered lists inPDFs
← Previous message | No next message

Responses inline.

> [AWK] Lbl is optional, per the ISO 32000 and ISO 14289 specs.

they are only optional insofar as if there is no bullet character or other kind of label in the page content, then that's fine, and no Lbl has to be present in the tagging structure for the list. But if there is page content that would be considered a bullet character or other kind of label in front of a list item, then PDF/UA clearly mandates that - for labels in list items as much as any other content - the right tag shall be used - and that would be the Lbl tag. No exceptions.

[AWK] You're right, regarding PDF/UA, I stand corrected. That said, it is an unfortunate requirement given the difficulty in making this type of repair. Tools like acrobat will need to make this easier, but I suspect that it will always be one of the more challenging types of repair.

> [AWK] .... As far as how the information is conveyed to AT if you use Lbl and Lbody, just Lbody, or even just put the text inside the LI directly - it is the same. The only difference with JAWS is that when you use Lbl the bullet is being read as if it is on its own line, which in my mind isn't a great way of announcing the bullet item.

The way you write a statement like this is possibly (as I might be reading too much into it) flawed in two ways:
- it silently equates AT to screenreaders
- it silently equates screenreaders to JAWS [I do know that you are writing it this way with only the best intentions, but...]

[AWK] You may be reading that into my words but that is not intended. I mentioned JAWS because others had related to this point, but I'm well aware of other tools, including for users other than those who need a screen reader. If anything, what it silently equates is way reader on Windows exposes list information to AT with the way that list information is exposed by PDF readers in general.

Envision AT that helps a dyslexic user do two things:
- make reading easier (or possible at all)
- help improve reading skills
There are a couple of ways to do this, for example by enlarging the page view, centering the current content in the document window, highlighting every piece of the content let's say word by word, while dimming everything around it (to reduce distraction by immediate context), speak out loud the word, additionally provide an alternate rendition of the word in a special font, then go on to the next word, etc.. If a person with dyslexia (many of them young people still learning the written language, and some of them overcoming their problems over time by working and learning very hard) never encounters a list label, he/she will not become familiar with the concept of 'list item labels'. Not good.

I could think of various other types of AT where not getting list labels right is just not the right thing to do. If it's there and is content (as opposed to decoration or some pagination side effect not conveying any meaning) - tag it! When tagging, always use the right tag (from the set of standard tags in PDF 1.7)! Not more, not less. Skipping or mis-tagging is bad, even if some groups of users wouldn't mind. At least that's the message of PDF/UA.

[AWK] I'd be interested in hearing about the other benefits of using lbl/lbody that you are thinking about. I'm not convinced that it is worth it given that user agents could do at least the things that you mentioned in the dyslexia example either way.