E-mail List Archives

Search E-mail List Archives for

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

From: Preast, Vanessa
Date: Fri, Jan 13 2017 3:43PM
Subject: Alt text in Word 2016: Indicate null image & which box to type in
No previous message | Next message →

Hello,

I just saw an instructional video from Microsoft that indicates to type "" within the description box for the alt text will tell the assistive technology to skip that image. Is this accurate? The following video states this information at 1:34 minutes: https://support.office.com/en-us/article/Use-alternative-text-for-images-and-objects-9c57ee44-bb48-40e3-aad4-7647fc1dba51

Also, at 45 seconds into this video, it indicates that we should write a title in the title and description in the description. But, this is different than the instructions on the NCDAE website (http://ncdae.org/resources/cheatsheets/word2013.php) which indicates that the alt text should go into the description box, not the title. What is considered best practice with entering alt text into Word 2016?

Thanks,
Vanessa

From: Jonathan Avila
Date: Sun, Jan 15 2017 6:43PM
Subject: Re: Alt text in Word 2016: Indicate null image & which box totype in
← Previous message | Next message →

> I just saw an instructional video from Microsoft that indicates to type "" within the description box for the alt text will tell the assistive technology to skip that image. Is this accurate?

I have never known that to be accurate in Word documents.

> Also, at 45 seconds into this video, it indicates that we should write a title in the title and description in the description. But, this is different than the instructions on the NCDAE website

The description field is the one that is announced by screen readers.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
See you at CSUN in March!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: L Snider
Date: Mon, Jan 16 2017 12:28PM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

Hi Jonathan,

Does that apply to both NVDA and JAWS? I remember a while back that some
people were recommending putting the same thing into the title and
description, because then it caught all screen readers. Do you think
Description is enough to catch almost everyone today?

Cheers

Lisa

On Sun, Jan 15, 2017 at 7:43 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> > Also, at 45 seconds into this video, it indicates that we should write a
> title in the title and description in the description. But, this is
> different than the instructions on the NCDAE website
>
> The description field is the one that is announced by screen readers.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 (Office)
>
>

From: Karlen Communications
Date: Mon, Jan 16 2017 12:46PM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

Is anyone getting the "" to work in Word, PowerPoint or Excel as null alt Text? Each time I try it, my screen reader says "graphic quote quote."

If I convert the document to tagged PDF, the Alt Text for the document is "quote quote" and I have to make it an Artifact.

Cheers, Karen

From: Chagnon | PubCom
Date: Mon, Jan 16 2017 5:37PM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

<< Do you think Description is enough to catch almost everyone today? >>

I'd take a look at the standards and decide.
All stakeholders are supposed to abide by the standards, including all assistive technology manufacturers as well as content creators (us).

Alt-text is an attribute on the <IMG> (web) or <FIGURE> (pdf) tag.
When a PDF is exported from Word, the Description field in Word is converted to Alt-text.
When a Word document is converted to HTML (or imported into an HTML webpage), I have no idea if the description field is converted to Alt-text in the HTML. In my experience, alt-text doesn't carry over from Word to HTML.

The Title tag is not alt-text and doesn't convert to alt-text. With some file formats, it might put a Title attribute on an element, but it is not standard practice to put a Title attribute on a graphic <IMG> or <FIGURE> tag. I also can't find anything in WCAG or PDF/UA that specifies a Title attribute on a graphic. (If so, please let me know!) Therefore, don't count on any assistive technology to recognize a Title attribute on a graphic because they're not required by the standard to recognize it on a graphic.

So in my reading of all this, the Description field should be enough to catch everyone using AT. If an AT isn't recognizing and presenting the Alt-text, then it's failing WCAG and PDF/UA international accessibility standards. And shame on the manufacturer!

FYI, an excellent summary of WCAG is on WebAIM's site, http://webaim.org/standards/wcag/WCAG2Checklist.pdf. Succinct, well-written, and comprehendible by mere mortals. This version is copyrighted 2016, so I'm assuming it's the latest version of their checklist.

--Bevi Chagnon

- - -
Bevi Chagnon | www.PubCom.com
Technologists, Consultants, Trainers, Designers, and Developers
for publishing & communication
| Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
- - -

From: L Snider
Date: Mon, Jan 16 2017 6:10PM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

Hi Bevi,

Thanks so much. From what I remember the title was a backup in case the
screen reader couldn't do the description, so both were filled out not just
one or the other. So it was like a back up in case, although then one could
get duplicate content from the two fields.

I was vague in my email, I never thought it was part of WCAG, it was a hack
used for some screen readers. I will see if I can find the references to
that, to see if I can identify the screen reader in question I also can't
remember if this was for Word docs that would remain Word docs (I know,
many aren't kept that way so it then changes things).

AT isn't perfect, as we all know, so it is just trying to find the best way
to catch the ones most people use...like everything else on the web! Some
days I wonder how far we have come in 18 years, and then other days I am
more optimistic!

Cheers

Lisa

On Mon, Jan 16, 2017 at 6:37 PM, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >
wrote:

> << Do you think Description is enough to catch almost everyone today? >>
>
> I'd take a look at the standards and decide.
> All stakeholders are supposed to abide by the standards, including all
> assistive technology manufacturers as well as content creators (us).
>
> Alt-text is an attribute on the <IMG> (web) or <FIGURE> (pdf) tag.
> When a PDF is exported from Word, the Description field in Word is
> converted to Alt-text.
> When a Word document is converted to HTML (or imported into an HTML
> webpage), I have no idea if the description field is converted to Alt-text
> in the HTML. In my experience, alt-text doesn't carry over from Word to
> HTML.
>
> The Title tag is not alt-text and doesn't convert to alt-text. With some
> file formats, it might put a Title attribute on an element, but it is not
> standard practice to put a Title attribute on a graphic <IMG> or <FIGURE>
> tag. I also can't find anything in WCAG or PDF/UA that specifies a Title
> attribute on a graphic. (If so, please let me know!) Therefore, don't count
> on any assistive technology to recognize a Title attribute on a graphic
> because they're not required by the standard to recognize it on a graphic.
>
> So in my reading of all this, the Description field should be enough to
> catch everyone using AT. If an AT isn't recognizing and presenting the
> Alt-text, then it's failing WCAG and PDF/UA international accessibility
> standards. And shame on the manufacturer!
>
> FYI, an excellent summary of WCAG is on WebAIM's site,
> http://webaim.org/standards/wcag/WCAG2Checklist.pdf. Succinct,
> well-written, and comprehendible by mere mortals. This version is
> copyrighted 2016, so I'm assuming it's the latest version of their
> checklist.
>
> --Bevi Chagnon
>
> - - -
> Bevi Chagnon | www.PubCom.com
> Technologists, Consultants, Trainers, Designers, and Developers
> for publishing & communication
> | Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
> - - -
>
>

From: L Snider
Date: Mon, Jan 16 2017 6:15PM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

Ah okay, I just found my notes on this one...I was wrong, it wasn't for
Word! If one uses LibreOffice, then you have to use the title field, not
the description field in order for the alt to go into the PDF properly. My
apologies for mixing the two programs!

Cheers

Lisa




On Mon, Jan 16, 2017 at 7:10 PM, L Snider < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Bevi,
>
> Thanks so much. From what I remember the title was a backup in case the
> screen reader couldn't do the description, so both were filled out not just
> one or the other. So it was like a back up in case, although then one could
> get duplicate content from the two fields.
>
> I was vague in my email, I never thought it was part of WCAG, it was a
> hack used for some screen readers. I will see if I can find the references
> to that, to see if I can identify the screen reader in question I also
> can't remember if this was for Word docs that would remain Word docs (I
> know, many aren't kept that way so it then changes things).
>
> AT isn't perfect, as we all know, so it is just trying to find the best
> way to catch the ones most people use...like everything else on the web!
> Some days I wonder how far we have come in 18 years, and then other days I
> am more optimistic!
>
> Cheers
>
> Lisa
>
>
> On Mon, Jan 16, 2017 at 6:37 PM, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> << Do you think Description is enough to catch almost everyone today? >>
>>
>> I'd take a look at the standards and decide.
>> All stakeholders are supposed to abide by the standards, including all
>> assistive technology manufacturers as well as content creators (us).
>>
>> Alt-text is an attribute on the <IMG> (web) or <FIGURE> (pdf) tag.
>> When a PDF is exported from Word, the Description field in Word is
>> converted to Alt-text.
>> When a Word document is converted to HTML (or imported into an HTML
>> webpage), I have no idea if the description field is converted to Alt-text
>> in the HTML. In my experience, alt-text doesn't carry over from Word to
>> HTML.
>>
>> The Title tag is not alt-text and doesn't convert to alt-text. With some
>> file formats, it might put a Title attribute on an element, but it is not
>> standard practice to put a Title attribute on a graphic <IMG> or <FIGURE>
>> tag. I also can't find anything in WCAG or PDF/UA that specifies a Title
>> attribute on a graphic. (If so, please let me know!) Therefore, don't count
>> on any assistive technology to recognize a Title attribute on a graphic
>> because they're not required by the standard to recognize it on a graphic.
>>
>> So in my reading of all this, the Description field should be enough to
>> catch everyone using AT. If an AT isn't recognizing and presenting the
>> Alt-text, then it's failing WCAG and PDF/UA international accessibility
>> standards. And shame on the manufacturer!
>>
>> FYI, an excellent summary of WCAG is on WebAIM's site,
>> http://webaim.org/standards/wcag/WCAG2Checklist.pdf. Succinct,
>> well-written, and comprehendible by mere mortals. This version is
>> copyrighted 2016, so I'm assuming it's the latest version of their
>> checklist.
>>
>> --Bevi Chagnon
>>
>> - - -
>> Bevi Chagnon | www.PubCom.com
>> Technologists, Consultants, Trainers, Designers, and Developers
>> for publishing & communication
>> | Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
>> - - -
>>
>>

From: L Snider
Date: Mon, Jan 16 2017 6:31PM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

My apologies for the multiple emails, Gmail seems to want to send my email
before I was done!

I found this was a good discussion of many programs and their use of
title/description. However, it is from 2014 and a lot has changed since
then:
http://terrillthompson.com/blog/548

As Jonathan and Bevi both confirmed, the Description is important. I do
wonder if the title is still better for Google Docs (as in the article
above), anyone know off hand? I won't be able to test this one right away,
but I was just curious.

I also found this in another source, and I always wondered if this was true
about the title?
When entering alternate text you will notice there is a* Title* and
*Description* field. The Title field is used to enter text that when read
to someone using a screen reader, it allows the user to decide whether to
listen to the text provided by the Description. However, it is generally
recommended that the main ALT text should be put into the Description field.

It is also interesting that Microsoft is saying to do both, even though
their note says to just use the Description field. I have come across this
before and wondered why they still recommend to do the title even though
they don't!
https://support.office.com/en-us/article/Make-your-Word-documents-accessible-d9bf3683-87ac-47ea-b91a-78dcacb3c66d#PickTab=Windows

Thanks everyone, appreciate your views on this!

Cheers

Lisa

On Mon, Jan 16, 2017 at 7:15 PM, L Snider < = EMAIL ADDRESS REMOVED = > wrote:

> Ah okay, I just found my notes on this one...I was wrong, it wasn't for
> Word! If one uses LibreOffice, then you have to use the title field, not
> the description field in order for the alt to go into the PDF properly. My
> apologies for mixing the two programs!
>
> Cheers
>
> Lisa
>
>
>
>
> On Mon, Jan 16, 2017 at 7:10 PM, L Snider < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi Bevi,
>>
>> Thanks so much. From what I remember the title was a backup in case the
>> screen reader couldn't do the description, so both were filled out not just
>> one or the other. So it was like a back up in case, although then one could
>> get duplicate content from the two fields.
>>
>> I was vague in my email, I never thought it was part of WCAG, it was a
>> hack used for some screen readers. I will see if I can find the references
>> to that, to see if I can identify the screen reader in question I also
>> can't remember if this was for Word docs that would remain Word docs (I
>> know, many aren't kept that way so it then changes things).
>>
>> AT isn't perfect, as we all know, so it is just trying to find the best
>> way to catch the ones most people use...like everything else on the web!
>> Some days I wonder how far we have come in 18 years, and then other days I
>> am more optimistic!
>>
>> Cheers
>>
>> Lisa
>>
>>
>> On Mon, Jan 16, 2017 at 6:37 PM, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> << Do you think Description is enough to catch almost everyone today? >>
>>>
>>> I'd take a look at the standards and decide.
>>> All stakeholders are supposed to abide by the standards, including all
>>> assistive technology manufacturers as well as content creators (us).
>>>
>>> Alt-text is an attribute on the <IMG> (web) or <FIGURE> (pdf) tag.
>>> When a PDF is exported from Word, the Description field in Word is
>>> converted to Alt-text.
>>> When a Word document is converted to HTML (or imported into an HTML
>>> webpage), I have no idea if the description field is converted to Alt-text
>>> in the HTML. In my experience, alt-text doesn't carry over from Word to
>>> HTML.
>>>
>>> The Title tag is not alt-text and doesn't convert to alt-text. With some
>>> file formats, it might put a Title attribute on an element, but it is not
>>> standard practice to put a Title attribute on a graphic <IMG> or <FIGURE>
>>> tag. I also can't find anything in WCAG or PDF/UA that specifies a Title
>>> attribute on a graphic. (If so, please let me know!) Therefore, don't count
>>> on any assistive technology to recognize a Title attribute on a graphic
>>> because they're not required by the standard to recognize it on a graphic.
>>>
>>> So in my reading of all this, the Description field should be enough to
>>> catch everyone using AT. If an AT isn't recognizing and presenting the
>>> Alt-text, then it's failing WCAG and PDF/UA international accessibility
>>> standards. And shame on the manufacturer!
>>>
>>> FYI, an excellent summary of WCAG is on WebAIM's site,
>>> http://webaim.org/standards/wcag/WCAG2Checklist.pdf. Succinct,
>>> well-written, and comprehendible by mere mortals. This version is
>>> copyrighted 2016, so I'm assuming it's the latest version of their
>>> checklist.
>>>
>>> --Bevi Chagnon
>>>
>>> - - -
>>> Bevi Chagnon | www.PubCom.com
>>> Technologists, Consultants, Trainers, Designers, and Developers
>>> for publishing & communication
>>> | Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
>>> - - -
>>>
>>>

From: Preast, Vanessa
Date: Tue, Jan 17 2017 7:29AM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

Is there a way to let Microsoft know that their instructional video may not be 100% accurate and ask them to fix the video? I'd really like to be able to direct people to their video when training our staff, because it seems most logical to me that the software manufacturer would be the expert on the most accessible way to use their own software.

From: _mallory
Date: Wed, Jan 18 2017 6:05AM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

I'm currently having the same unclear situation with PowerPoints, especially
tables (which are required to have "alt text" even if you have real tables)
and MathML, where so far it appears for our JAWS users we need to give that
Math some alt text as MathPlayer doesn't seem to allow JAWS to read the
equations.

I'm actually busy trying to figure out this stuff now and it's still fuzzy in
places, while vendors want clear guidelines!

cheers,
_mallory

On Mon, Jan 16, 2017 at 07:31:51PM -0600, L Snider wrote:
> It is also interesting that Microsoft is saying to do both, even though
> their note says to just use the Description field. I have come across this
> before and wondered why they still recommend to do the title even though
> they don't!
> https://support.office.com/en-us/article/Make-your-Word-documents-accessible-d9bf3683-87ac-47ea-b91a-78dcacb3c66d#PickTab=Windows
>
> Thanks everyone, appreciate your views on this!
>
> Cheers
>
> Lisa
>
> On Mon, Jan 16, 2017 at 7:15 PM, L Snider < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Ah okay, I just found my notes on this one...I was wrong, it wasn't for
> > Word! If one uses LibreOffice, then you have to use the title field, not
> > the description field in order for the alt to go into the PDF properly. My
> > apologies for mixing the two programs!
> >
> > Cheers
> >
> > Lisa
> >
> >
> >
> >
> > On Mon, Jan 16, 2017 at 7:10 PM, L Snider < = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Hi Bevi,
> >>
> >> Thanks so much. From what I remember the title was a backup in case the
> >> screen reader couldn't do the description, so both were filled out not just
> >> one or the other. So it was like a back up in case, although then one could
> >> get duplicate content from the two fields.
> >>
> >> I was vague in my email, I never thought it was part of WCAG, it was a
> >> hack used for some screen readers. I will see if I can find the references
> >> to that, to see if I can identify the screen reader in question I also
> >> can't remember if this was for Word docs that would remain Word docs (I
> >> know, many aren't kept that way so it then changes things).
> >>
> >> AT isn't perfect, as we all know, so it is just trying to find the best
> >> way to catch the ones most people use...like everything else on the web!
> >> Some days I wonder how far we have come in 18 years, and then other days I
> >> am more optimistic!
> >>
> >> Cheers
> >>
> >> Lisa
> >>
> >>
> >> On Mon, Jan 16, 2017 at 6:37 PM, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >>> << Do you think Description is enough to catch almost everyone today? >>
> >>>
> >>> I'd take a look at the standards and decide.
> >>> All stakeholders are supposed to abide by the standards, including all
> >>> assistive technology manufacturers as well as content creators (us).
> >>>
> >>> Alt-text is an attribute on the <IMG> (web) or <FIGURE> (pdf) tag.
> >>> When a PDF is exported from Word, the Description field in Word is
> >>> converted to Alt-text.
> >>> When a Word document is converted to HTML (or imported into an HTML
> >>> webpage), I have no idea if the description field is converted to Alt-text
> >>> in the HTML. In my experience, alt-text doesn't carry over from Word to
> >>> HTML.
> >>>
> >>> The Title tag is not alt-text and doesn't convert to alt-text. With some
> >>> file formats, it might put a Title attribute on an element, but it is not
> >>> standard practice to put a Title attribute on a graphic <IMG> or <FIGURE>
> >>> tag. I also can't find anything in WCAG or PDF/UA that specifies a Title
> >>> attribute on a graphic. (If so, please let me know!) Therefore, don't count
> >>> on any assistive technology to recognize a Title attribute on a graphic
> >>> because they're not required by the standard to recognize it on a graphic.
> >>>
> >>> So in my reading of all this, the Description field should be enough to
> >>> catch everyone using AT. If an AT isn't recognizing and presenting the
> >>> Alt-text, then it's failing WCAG and PDF/UA international accessibility
> >>> standards. And shame on the manufacturer!
> >>>
> >>> FYI, an excellent summary of WCAG is on WebAIM's site,
> >>> http://webaim.org/standards/wcag/WCAG2Checklist.pdf. Succinct,
> >>> well-written, and comprehendible by mere mortals. This version is
> >>> copyrighted 2016, so I'm assuming it's the latest version of their
> >>> checklist.
> >>>
> >>> --Bevi Chagnon
> >>>
> >>> - - -
> >>> Bevi Chagnon | www.PubCom.com
> >>> Technologists, Consultants, Trainers, Designers, and Developers
> >>> for publishing & communication
> >>> | Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
> >>> - - -
> >>>
> >>>

From: Jonathan Avila
Date: Wed, Jan 18 2017 6:21PM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

> Does that apply to both NVDA and JAWS? I remember a while back that some people were recommending putting the same thing into the title and description, because then it caught all screen readers. Do you think Description is enough to catch almost everyone today?

JAWS and NVDA both use the description field as the alt text for images in MS Word. I can't speak to other word processing products and other screen readers as I have not tested those recently.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
See you at CSUN in March!

From: Moore,Michael (Accessibility) (HHSC)
Date: Thu, Jan 19 2017 7:50AM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

The behavior that I get with Word 2013 and JAWS 17, admittedly a little out of date, is somewhat bizarre.

My test document has three images. All images are placed in-line with the text

1. Picture with title and description
2. Picture with title only
3. Picture with description only

1. In edit mode reading by line nothing is announced for any of images JAWS just says blank.
2. In edit mode reading by word the title is announced if it is present.
3. In edit mode reading by character the title is announced if present. If only the description is present the description is read and the first word of the description is announced in the voice used for the title.
4. In edit mode reading using say all. Both the title and description are read and JAWS tells you which is the title and an which is the description unless only a description is present. In this case JAWS just reads the description. Also in this mode the title and description are read twice for each image and the size of the image is announced.
5. In quick keys mode reading by paragraph. JAWS will only announce the title and ignores the description. Thus if only a description is present JAWS will announce "blank" for the image.
6. In quick keys mode reading by graphic. JAWS will only announce the description and ignores the title. Thus if only a title is present JAWS will only tell you that a picture is present.

JAWS Keys used for reference:

In edit mode - moving forward through the document
Reading by line use the down arrow
Reading by word use control+left arrow
Reading by character use left arrow
Reading say all go to the top of the page control+home then insert+down arrow.

To get to quick keys mode use insert+z
Reading by paragraph use the p key
Reading by graphic use the g key

I am not sure what all of this means in terms of what to recommend a best practice for graphics is word documents. Just that life as a JAWS user can be interesting. If the document is to be converted to PDF or HTML for publication use the description field. This will save you from having to enter the alt text again. If you all collaborating on the document with a screen reader user (JAWS or other) I would ask them how they would prefer the graphics to be labelled.

Mike Moore
EIR (Electronic Information Resources) Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

Making electronic information and services accessible to people with disabilities is everyone's job. I am here to help.

From: L Snider
Date: Thu, Jan 19 2017 8:42AM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

Hi Mike and Jonathan,

Thanks so much! Great list Mike!

Cheers

Lisa

On Thu, Jan 19, 2017 at 8:50 AM, Moore,Michael (Accessibility) (HHSC) <
= EMAIL ADDRESS REMOVED = > wrote:

> The behavior that I get with Word 2013 and JAWS 17, admittedly a little
> out of date, is somewhat bizarre.
>
> My test document has three images. All images are placed in-line with the
> text
>
> 1. Picture with title and description
> 2. Picture with title only
> 3. Picture with description only
>
> 1. In edit mode reading by line nothing is announced for any of images
> JAWS just says blank.
> 2. In edit mode reading by word the title is announced if it is present.
> 3. In edit mode reading by character the title is announced if present. If
> only the description is present the description is read and the first word
> of the description is announced in the voice used for the title.
> 4. In edit mode reading using say all. Both the title and description are
> read and JAWS tells you which is the title and an which is the description
> unless only a description is present. In this case JAWS just reads the
> description. Also in this mode the title and description are read twice for
> each image and the size of the image is announced.
> 5. In quick keys mode reading by paragraph. JAWS will only announce the
> title and ignores the description. Thus if only a description is present
> JAWS will announce "blank" for the image.
> 6. In quick keys mode reading by graphic. JAWS will only announce the
> description and ignores the title. Thus if only a title is present JAWS
> will only tell you that a picture is present.
>
> JAWS Keys used for reference:
>
> In edit mode - moving forward through the document
> Reading by line use the down arrow
> Reading by word use control+left arrow
> Reading by character use left arrow
> Reading say all go to the top of the page control+home then insert+down
> arrow.
>
> To get to quick keys mode use insert+z
> Reading by paragraph use the p key
> Reading by graphic use the g key
>
> I am not sure what all of this means in terms of what to recommend a best
> practice for graphics is word documents. Just that life as a JAWS user can
> be interesting. If the document is to be converted to PDF or HTML for
> publication use the description field. This will save you from having to
> enter the alt text again. If you all collaborating on the document with a
> screen reader user (JAWS or other) I would ask them how they would prefer
> the graphics to be labelled.
>
> Mike Moore
> EIR (Electronic Information Resources) Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
>
> Making electronic information and services accessible to people with
> disabilities is everyone's job. I am here to help.
>
>

From: Chagnon | PubCom
Date: Thu, Jan 19 2017 10:04AM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

IIRC, some of these JAWS with Word behaviors are errors, not the final intended response, especially numbers 5 and 6 in Michael's list, using quick keys mode.

Again, we must build content to meet the standards, not the weird behaviors of assistive technologies. The standards say "Alt-Text" not "Title."

Otherwise we'll go crazy because JAWS reads something one way, NVDA another, Voice Over another...we'll never get anything published and fully accessible!

AT manufacturers are required to meet the same standards. That's why they are standards!

If Quick Keys in JAWS isn't giving the correct response, then its customer base -- JAWS users -- must cite them on this.

--Bevi Chagnon


On Thu, Jan 19, 2017 at 8:50 AM, Moore,Michael (Accessibility) (HHSC) < = EMAIL ADDRESS REMOVED = > wrote:

> The behavior that I get with Word 2013 and JAWS 17, admittedly a
> little out of date, is somewhat bizarre.
>
> My test document has three images. All images are placed in-line with
> the text
>
> 1. Picture with title and description
> 2. Picture with title only
> 3. Picture with description only
>
> 1. In edit mode reading by line nothing is announced for any of images
> JAWS just says blank.
> 2. In edit mode reading by word the title is announced if it is present.
> 3. In edit mode reading by character the title is announced if
> present. If only the description is present the description is read
> and the first word of the description is announced in the voice used for the title.
> 4. In edit mode reading using say all. Both the title and description
> are read and JAWS tells you which is the title and an which is the
> description unless only a description is present. In this case JAWS
> just reads the description. Also in this mode the title and
> description are read twice for each image and the size of the image is announced.
> 5. In quick keys mode reading by paragraph. JAWS will only announce
> the title and ignores the description. Thus if only a description is
> present JAWS will announce "blank" for the image.
> 6. In quick keys mode reading by graphic. JAWS will only announce the
> description and ignores the title. Thus if only a title is present
> JAWS will only tell you that a picture is present.
>
> JAWS Keys used for reference:
>
> In edit mode - moving forward through the document Reading by line use
> the down arrow Reading by word use control+left arrow Reading by
> character use left arrow Reading say all go to the top of the page
> control+home then insert+down arrow.
>
> To get to quick keys mode use insert+z Reading by paragraph use the p
> key Reading by graphic use the g key
>
> I am not sure what all of this means in terms of what to recommend a
> best practice for graphics is word documents. Just that life as a JAWS
> user can be interesting. If the document is to be converted to PDF or
> HTML for publication use the description field. This will save you
> from having to enter the alt text again. If you all collaborating on
> the document with a screen reader user (JAWS or other) I would ask
> them how they would prefer the graphics to be labelled.
>
> Mike Moore
> EIR (Electronic Information Resources) Accessibility Coordinator Texas
> Health and Human Services Commission Civil Rights Office
> (512) 438-3431 (Office)

From: L Snider
Date: Thu, Jan 19 2017 11:00AM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

Hi Bevi,

Thanks so much for that information. I am wondering if the new version of
Word would make a difference here, do you know off hand?

Cheers

Lisa

On Thu, Jan 19, 2017 at 11:04 AM, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >
wrote:

> IIRC, some of these JAWS with Word behaviors are errors, not the final
> intended response, especially numbers 5 and 6 in Michael's list, using
> quick keys mode.
>
> Again, we must build content to meet the standards, not the weird
> behaviors of assistive technologies. The standards say "Alt-Text" not
> "Title."
>
> Otherwise we'll go crazy because JAWS reads something one way, NVDA
> another, Voice Over another...we'll never get anything published and fully
> accessible!
>
> AT manufacturers are required to meet the same standards. That's why they
> are standards!
>
> If Quick Keys in JAWS isn't giving the correct response, then its customer
> base -- JAWS users -- must cite them on this.
>
> --Bevi Chagnon
>
>
> On Thu, Jan 19, 2017 at 8:50 AM, Moore,Michael (Accessibility) (HHSC) <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > The behavior that I get with Word 2013 and JAWS 17, admittedly a
> > little out of date, is somewhat bizarre.
> >
> > My test document has three images. All images are placed in-line with
> > the text
> >
> > 1. Picture with title and description
> > 2. Picture with title only
> > 3. Picture with description only
> >
> > 1. In edit mode reading by line nothing is announced for any of images
> > JAWS just says blank.
> > 2. In edit mode reading by word the title is announced if it is present.
> > 3. In edit mode reading by character the title is announced if
> > present. If only the description is present the description is read
> > and the first word of the description is announced in the voice used for
> the title.
> > 4. In edit mode reading using say all. Both the title and description
> > are read and JAWS tells you which is the title and an which is the
> > description unless only a description is present. In this case JAWS
> > just reads the description. Also in this mode the title and
> > description are read twice for each image and the size of the image is
> announced.
> > 5. In quick keys mode reading by paragraph. JAWS will only announce
> > the title and ignores the description. Thus if only a description is
> > present JAWS will announce "blank" for the image.
> > 6. In quick keys mode reading by graphic. JAWS will only announce the
> > description and ignores the title. Thus if only a title is present
> > JAWS will only tell you that a picture is present.
> >
> > JAWS Keys used for reference:
> >
> > In edit mode - moving forward through the document Reading by line use
> > the down arrow Reading by word use control+left arrow Reading by
> > character use left arrow Reading say all go to the top of the page
> > control+home then insert+down arrow.
> >
> > To get to quick keys mode use insert+z Reading by paragraph use the p
> > key Reading by graphic use the g key
> >
> > I am not sure what all of this means in terms of what to recommend a
> > best practice for graphics is word documents. Just that life as a JAWS
> > user can be interesting. If the document is to be converted to PDF or
> > HTML for publication use the description field. This will save you
> > from having to enter the alt text again. If you all collaborating on
> > the document with a screen reader user (JAWS or other) I would ask
> > them how they would prefer the graphics to be labelled.
> >
> > Mike Moore
> > EIR (Electronic Information Resources) Accessibility Coordinator Texas
> > Health and Human Services Commission Civil Rights Office
> > (512) 438-3431 (Office)
>
> > > > >

From: Jonathan Avila
Date: Fri, Jan 20 2017 8:12PM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

> The behavior that I get with Word 2013 and JAWS 17, admittedly a little out of date, is somewhat bizarre.

Mike and others, I re-ran JAWS 17 and 18 and got different results than I previously did with JAWS. Previously the other day JAWS was not announcing the title field of the alt text when using the up/down arrow keys. I re-tested after seeing your results and now it is announcing both. I do wonder if there is some setting in JAWS or change to shared components in JAWS that may affect what is announced as my results have been inconsistent.

I apologize that I can no longer reproduce the results from the other day.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
See you at CSUN in March!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: Moore,Michael (Accessibility) (HHSC)
Date: Mon, Jan 23 2017 7:46AM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

We have had a saying around our offices for a while - JAWS installations are like snowflakes...

Mike Moore
EIR (Electronic Information Resources) Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

Making electronic information and services accessible to people with disabilities is everyone's job. I am here to help.

From: JP Jamous
Date: Mon, Jan 23 2017 7:54AM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | Next message →

Although JAWS has always been my primary SR since 1998, I hate some of the junk that were added to it. I keep filing suggestions with VFO with various apps. They tend to be leaning more towards verbose output rather than making that an option. A prime example if you have a fieldset with a legend. I really don't want to hear the legend whenever I move through each radio button. If the purpose is to apply to a certain type of audience with cognitive disabilities, I welcome that. However, allow me to control this through the settings.

The above concept applies to Outlook 2016 calendar, which I filed a bug with them last week about. I keep hoping that someday we can get those manufacturers to ensure their screen readers read similarly. I hope to have it done in my lifetime, but it may not happen.

From: Jim Allan
Date: Mon, Jan 23 2017 11:46AM
Subject: Re: Alt text in Word 2016: Indicate null image & which box to type in
← Previous message | No next message

Updated for JAWS 18 and Word 2016
things that are added to the word 2013 and jaws 17 behavior are marked
by **additional
stuff spoken** and bold
things that are not spoken as previous version are marked with [[stuff no
longer true]]

On Thu, Jan 19, 2017 at 8:50 AM, Moore,Michael (Accessibility) (HHSC) <
= EMAIL ADDRESS REMOVED = > wrote:

> The behavior that I get with Word 2013 and JAWS 17, admittedly a little
> out of date, is somewhat bizarre.
>
> My test document has three images. All images are placed in-line with the
> text
>
> 1. Picture with title and description
> 2. Picture with title only
> 3. Picture with description only
>
> JAWS 18 and Word 2016
1. In edit mode reading by line nothing is announced for any of images JAWS
just says blank.
2. In edit mode reading by word the title is announced if it is present.
3. In edit mode reading by character the title is announced if present. If
only the description is present the description is read and the first word
of the description is announced in the voice used for the title.**and The
dimensions of the graphic is announced. All images are followed by the
word "graphic"**
4. In edit mode reading using say all. **All are preceded by the word
"graphic". All dimensions are announced** Both the title and description
are read and JAWS tells you which is the title and an which is the
description unless only a description is present. In this case JAWS just
reads the description. the size of the image is announced. [[Also in this
mode the title and description are read twice for each image]].
5. In quick keys mode reading by paragraph. JAWS will only announce the
title and ignores the description. Thus if only a description is present
JAWS will announce "blank" for the image. **if title present the word
"graphic" is announced first, title is read and dimensions are spoken**
6. In quick keys mode reading by graphic. JAWS will only announce the
description and ignores the title. Thus if only a title is present JAWS
will only tell you that a picture is present.

**the word "picture" is announced before each image, no dimensions spoken.**
NVDA 2016.4 and Word 2016
1. In edit mode reading line by line all are preceded by "graphic" If
description is present it is given preference and spoken. If only title is
present it is spoken.
2. In edit mode reading by word all are preceded by "graphic" If
description is present it is given preference and spoken. If only title is
present it is spoken.
3. In edit mode reading by character all are preceded by "graphic" If
description is present it is given preference and spoken. If only title is
present it is spoken.
4. In quick keys mode reading by graphic all are preceded by "graphic" If
description is present it is given preference and spoken. If only title is
present it is spoken.


Jaws 17 and Word 2013

>
> 1. In edit mode reading by line nothing is announced for any of images
> JAWS just says blank.
>
> 2. In edit mode reading by word the title is announced if it is present.
>
> 3. In edit mode reading by character the title is announced if present. If
> only the description is present the description is read and the first word
> of the description is announced in the voice used for the title.
>
> 4. In edit mode reading using say all. Both the title and description are
> read and JAWS tells you which is the title and an which is the description
> unless only a description is present. In this case JAWS just reads the
> description. Also in this mode the title and description are read twice for
> each image and the size of the image is announced.
>
> 5. In quick keys mode reading by paragraph. JAWS will only announce the
> title and ignores the description. Thus if only a description is present
> JAWS will announce "blank" for the image.
>
> 6. In quick keys mode reading by graphic. JAWS will only announce the
> description and ignores the title. Thus if only a title is present JAWS
> will only tell you that a picture is present.
>
> JAWS Keys used for reference:
>
> In edit mode - moving forward through the document
> Reading by line use the down arrow
> Reading by word use control+left arrow
> Reading by character use left arrow
> Reading say all go to the top of the page control+home then insert+down
> arrow.
>
> To get to quick keys mode use insert+z
> Reading by paragraph use the p key
> Reading by graphic use the g key
>
> I am not sure what all of this means in terms of what to recommend a best
> practice for graphics is word documents. Just that life as a JAWS user can
> be interesting. If the document is to be converted to PDF or HTML for
> publication use the description field. This will save you from having to
> enter the alt text again. If you all collaborating on the document with a
> screen reader user (JAWS or other) I would ask them how they would prefer
> the graphics to be labelled.
>
> Mike Moore
> EIR (Electronic Information Resources) Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
>
> Making electronic information and services accessible to people with
> disabilities is everyone's job. I am here to help.
>
>