E-mail List Archives
Thread: Current best practice/standard/guideline for linking to non-html files?
Number of posts in this thread: 16 (In chronological order)
From: Angela French
Date: Mon, Oct 20 2014 6:08PM
Subject: Current best practice/standard/guideline for linking to non-html files?
No previous message | Next message →
Hello,
In our current website we identify links to non-html documents with a document type icon and include the icon in the hyper-texted link label. Here is an example page<http://www.sbctc.edu/college/_g-abe_cbsmeetinginfo.aspx>;.
We are in the midst of a redesign and it has been suggested that identifying document types is no longer needed either for accessibility or usability. I disagree, but would like to know your thoughts on this.
Thank you,
Angela French
Internet Specialist
State Board for Community and Technical Colleges
360-704-4316
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
www.checkoutacollege.com<;http://www.checkoutacollege.com>;
www.sbctc.edu<;http://www.sbctc.edu>;
From: Jonathan Avila
Date: Mon, Oct 20 2014 6:14PM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
> We are in the midst of a redesign and it has been suggested that identifying document types is no longer needed either for accessibility or usability. I disagree, but would like to know your thoughts on this.
I think it's still important but I don't consider it a conformance failure when it's not done. The argument can be made that all people are equally at a disadvantage because the link type is ambiguous to all.
Benefits for indicating the type apply to people with motor, cognitive, and visual impairments. Traversing a link that is not the intended link can have more serious consequences for people with disabilities because they have to return to where they were. An argument can also be made from mobile where large documents can take a long time to download or cause the user to incur fees for data usage.
Jonathan
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Angela French
Sent: Monday, October 20, 2014 8:08 PM
To: WebAim Forum ( = EMAIL ADDRESS REMOVED = )
Subject: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
Hello,
In our current website we identify links to non-html documents with a document type icon and include the icon in the hyper-texted link label. Here is an example page<http://www.sbctc.edu/college/_g-abe_cbsmeetinginfo.aspx>;.
We are in the midst of a redesign and it has been suggested that identifying document types is no longer needed either for accessibility or usability. I disagree, but would like to know your thoughts on this.
Thank you,
Angela French
Internet Specialist
State Board for Community and Technical Colleges
360-704-4316
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
www.checkoutacollege.com<;http://www.checkoutacollege.com>;
www.sbctc.edu<;http://www.sbctc.edu>;
From: Mallory van Achterberg
Date: Tue, Oct 21 2014 4:34AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
> Benefits for indicating the type apply to people with motor, cognitive, and visual impairments. Traversing a link that is not the intended link can have more serious consequences for people with disabilities because they have to return to where they were. An argument can also be made from mobile where large documents can take a long time to download or cause the user to incur fees for data usage.
>
> Jonathan
Benefits for users who need to keep their rates in mind (mobile users)
and those who know whether or not they even have an application
available that can open it. For example, if I knew I wanted to avoid
.pdf files because I have a crap phone, I now have the knowledge to
stay away.
I consider it a usability issue.
_mallory
From: Birkir R. Gunnarsson
Date: Tue, Oct 21 2014 6:44AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
Benefits of indicating file types, )ellaborating on what´s already been stated).
Users, particularly users with disabilities, may need to open files in
"unusual" applications for maximum accessibility (say, they would
always want to use AdobeReader rather than opening a PDF document in
the browser). By indicating the filetype on the link you give them an
opportunity to take the appropriate action, such as right click and
save the file rather than opening it.
Yes, users can configure their own workstations or mobile devices to
always open a certain filetype in a certain application, but users may
not always be using their own workstations or devices when browsing
the internet.
For people with disabilities this is a very important usability issue.
Not indicating that a link points to a filetype cannot be called under
a WCAG violation, as far as I can see, (and I have tried) unless this
information is not available visually.
If this info is available visually (e.g. by including an icon as a CSS
.background image), it would, however, be a violation of WCAG SC 1.1.1
not to provide that info in some other way.
Cheers
On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>> Benefits for indicating the type apply to people with motor, cognitive,
>> and visual impairments. Traversing a link that is not the intended link
>> can have more serious consequences for people with disabilities because
>> they have to return to where they were. An argument can also be made from
>> mobile where large documents can take a long time to download or cause the
>> user to incur fees for data usage.
>>
>> Jonathan
>
> Benefits for users who need to keep their rates in mind (mobile users)
> and those who know whether or not they even have an application
> available that can open it. For example, if I knew I wanted to avoid
> .pdf files because I have a crap phone, I now have the knowledge to
> stay away.
>
> I consider it a usability issue.
> _mallory
> > > >
--
Work hard. Have fun. Make history.
From: Bim Egan
Date: Tue, Oct 21 2014 7:43AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
Just adding an extra layer of support for clearly identifying links that
open new formats:
As Birkir said, disabled people may need to save files rather than have
them open up within a browser "shell". For screen reader users the
reason is that there's little accessibility support in the Adobe Reader
and MS Office "shells" produced by Internet Explorer. The reading flow
is often broken, it's not possible to get a list of links or headings, etc.
These "shells" also make it nearly impossible for keyboard only users
(including screen reader users), to use keyboard navigation to either
return to the previous page or navigate between open browser tabs.
The toolbar is also changed, it's neither the same as the native
application, nor the originating browser toolbar.
Users may also find it difficult to prevent the browser shell opening,
for instance because their preferred application for that format has a
default setting that allows the browser to take over. To cap it all, if
the user has Windows7 .NET 4.5, they may be unable to change the way
that MS Office files, like Word or Excel, are opened from web pages. My
understanding is that it requires a change to the Registry. It used to
be a folder option under XP, but isn't under Win 7 .NET 4.5.
With all the problems that change of format create for disabled people,
I wonder if changing from HTML to other formats isn't something that
should be covered under SC 3.2.5 Change on Request. New window opening,
which is covered by this Success Criteria is a minor inconvenience
compared to changing the format.
Bim
On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
> Benefits of indicating file types, )ellaborating on what´s already been stated).
> Users, particularly users with disabilities, may need to open files in
> "unusual" applications for maximum accessibility (say, they would
> always want to use AdobeReader rather than opening a PDF document in
> the browser). By indicating the filetype on the link you give them an
> opportunity to take the appropriate action, such as right click and
> save the file rather than opening it.
> Yes, users can configure their own workstations or mobile devices to
> always open a certain filetype in a certain application, but users may
> not always be using their own workstations or devices when browsing
> the internet.
> For people with disabilities this is a very important usability issue.
>
>
> Not indicating that a link points to a filetype cannot be called under
> a WCAG violation, as far as I can see, (and I have tried) unless this
> information is not available visually.
> If this info is available visually (e.g. by including an icon as a CSS
> .background image), it would, however, be a violation of WCAG SC 1.1.1
> not to provide that info in some other way.
> Cheers
>
>
>
> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>> Benefits for indicating the type apply to people with motor, cognitive,
>>> and visual impairments. Traversing a link that is not the intended link
>>> can have more serious consequences for people with disabilities because
>>> they have to return to where they were. An argument can also be made from
>>> mobile where large documents can take a long time to download or cause the
>>> user to incur fees for data usage.
>>>
>>> Jonathan
>> Benefits for users who need to keep their rates in mind (mobile users)
>> and those who know whether or not they even have an application
>> available that can open it. For example, if I knew I wanted to avoid
>> .pdf files because I have a crap phone, I now have the knowledge to
>> stay away.
>>
>> I consider it a usability issue.
>> _mallory
>> >> >> >>
>
From: Andrew Kirkpatrick
Date: Tue, Oct 21 2014 8:08AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
Bim wrote the following, but there are a few inaccurate statements:
As Birkir said, disabled people may need to save files rather than have them open up within a browser "shell". For screen reader users the reason is that there's little accessibility support in the Adobe Reader and MS Office "shells" produced by Internet Explorer. The reading flow is often broken, it's not possible to get a list of links or headings, etc.
These "shells" also make it nearly impossible for keyboard only users (including screen reader users), to use keyboard navigation to either
return to the previous page or navigate between open browser tabs.
The toolbar is also changed, it's neither the same as the native application, nor the originating browser toolbar.
For Adobe Reader in IE the reading flow matches what you get in Reader on its own. Of course, if the PDF is incorrectly tagged then the reader order may be incorrect, but that is an authoring issue rather than a technology issue.
Lists and headers read correctly when viewing a PDF in IE with Reader.
I can move from the PDF document to another tab from the keyboard, but usually need to hit escape to extract the focus from the object within the PDF that it is currently on first.
Reader doesn't change the toolbar in IE, but does add a toolbar specific to Reader, and this is independently keyboard navigable.
In short, I take exception to the statement that there is little accessibility support in the Reader plug in for IE.
AWK
On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
> Benefits of indicating file types, )ellaborating on what´s already been stated).
> Users, particularly users with disabilities, may need to open files in
> "unusual" applications for maximum accessibility (say, they would
> always want to use AdobeReader rather than opening a PDF document in
> the browser). By indicating the filetype on the link you give them an
> opportunity to take the appropriate action, such as right click and
> save the file rather than opening it.
> Yes, users can configure their own workstations or mobile devices to
> always open a certain filetype in a certain application, but users may
> not always be using their own workstations or devices when browsing
> the internet.
> For people with disabilities this is a very important usability issue.
>
>
> Not indicating that a link points to a filetype cannot be called under
> a WCAG violation, as far as I can see, (and I have tried) unless this
> information is not available visually.
> If this info is available visually (e.g. by including an icon as a CSS
> .background image), it would, however, be a violation of WCAG SC 1.1.1
> not to provide that info in some other way.
> Cheers
>
>
>
> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>> Benefits for indicating the type apply to people with motor,
>>> cognitive, and visual impairments. Traversing a link that is not
>>> the intended link can have more serious consequences for people with
>>> disabilities because they have to return to where they were. An
>>> argument can also be made from mobile where large documents can take
>>> a long time to download or cause the user to incur fees for data usage.
>>>
>>> Jonathan
>> Benefits for users who need to keep their rates in mind (mobile
>> users) and those who know whether or not they even have an
>> application available that can open it. For example, if I knew I
>> wanted to avoid .pdf files because I have a crap phone, I now have
>> the knowledge to stay away.
>>
>> I consider it a usability issue.
>> _mallory
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
>
From: Angela French
Date: Tue, Oct 21 2014 9:38AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
Given that Adobe Reader and IE poorly support the reading of PDFs by screen reader users, what is the preferred application that is used?
Angela French
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bim Egan
Sent: Tuesday, October 21, 2014 6:43 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
Just adding an extra layer of support for clearly identifying links that open new formats:
As Birkir said, disabled people may need to save files rather than have them open up within a browser "shell". For screen reader users the reason is that there's little accessibility support in the Adobe Reader and MS Office "shells" produced by Internet Explorer. The reading flow is often broken, it's not possible to get a list of links or headings, etc.
These "shells" also make it nearly impossible for keyboard only users (including screen reader users), to use keyboard navigation to either
return to the previous page or navigate between open browser tabs.
The toolbar is also changed, it's neither the same as the native application, nor the originating browser toolbar.
Users may also find it difficult to prevent the browser shell opening, for instance because their preferred application for that format has a default setting that allows the browser to take over. To cap it all, if the user has Windows7 .NET 4.5, they may be unable to change the way that MS Office files, like Word or Excel, are opened from web pages. My understanding is that it requires a change to the Registry. It used to be a folder option under XP, but isn't under Win 7 .NET 4.5.
With all the problems that change of format create for disabled people, I wonder if changing from HTML to other formats isn't something that should be covered under SC 3.2.5 Change on Request. New window opening, which is covered by this Success Criteria is a minor inconvenience compared to changing the format.
Bim
On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
> Benefits of indicating file types, )ellaborating on what´s already been stated).
> Users, particularly users with disabilities, may need to open files in
> "unusual" applications for maximum accessibility (say, they would
> always want to use AdobeReader rather than opening a PDF document in
> the browser). By indicating the filetype on the link you give them an
> opportunity to take the appropriate action, such as right click and
> save the file rather than opening it.
> Yes, users can configure their own workstations or mobile devices to
> always open a certain filetype in a certain application, but users may
> not always be using their own workstations or devices when browsing
> the internet.
> For people with disabilities this is a very important usability issue.
>
>
> Not indicating that a link points to a filetype cannot be called under
> a WCAG violation, as far as I can see, (and I have tried) unless this
> information is not available visually.
> If this info is available visually (e.g. by including an icon as a CSS
> .background image), it would, however, be a violation of WCAG SC 1.1.1
> not to provide that info in some other way.
> Cheers
>
>
>
> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>> Benefits for indicating the type apply to people with motor,
>>> cognitive, and visual impairments. Traversing a link that is not
>>> the intended link can have more serious consequences for people with
>>> disabilities because they have to return to where they were. An
>>> argument can also be made from mobile where large documents can take
>>> a long time to download or cause the user to incur fees for data usage.
>>>
>>> Jonathan
>> Benefits for users who need to keep their rates in mind (mobile
>> users) and those who know whether or not they even have an
>> application available that can open it. For example, if I knew I
>> wanted to avoid .pdf files because I have a crap phone, I now have
>> the knowledge to stay away.
>>
>> I consider it a usability issue.
>> _mallory
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
>
From: Andrews, David B (DEED)
Date: Tue, Oct 21 2014 9:42AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
I think that most screen reader users employ Adobe Reader to read PDF's, since it is default on most systems. Best results are obtained by not using the IE plug-in but using Adobe Reader itself.
Dave
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Angela French
Sent: Tuesday, October 21, 2014 10:38 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
Given that Adobe Reader and IE poorly support the reading of PDFs by screen reader users, what is the preferred application that is used?
Angela French
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bim Egan
Sent: Tuesday, October 21, 2014 6:43 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
Just adding an extra layer of support for clearly identifying links that open new formats:
As Birkir said, disabled people may need to save files rather than have them open up within a browser "shell". For screen reader users the reason is that there's little accessibility support in the Adobe Reader and MS Office "shells" produced by Internet Explorer. The reading flow is often broken, it's not possible to get a list of links or headings, etc.
These "shells" also make it nearly impossible for keyboard only users (including screen reader users), to use keyboard navigation to either
return to the previous page or navigate between open browser tabs.
The toolbar is also changed, it's neither the same as the native application, nor the originating browser toolbar.
Users may also find it difficult to prevent the browser shell opening, for instance because their preferred application for that format has a default setting that allows the browser to take over. To cap it all, if the user has Windows7 .NET 4.5, they may be unable to change the way that MS Office files, like Word or Excel, are opened from web pages. My understanding is that it requires a change to the Registry. It used to be a folder option under XP, but isn't under Win 7 .NET 4.5.
With all the problems that change of format create for disabled people, I wonder if changing from HTML to other formats isn't something that should be covered under SC 3.2.5 Change on Request. New window opening, which is covered by this Success Criteria is a minor inconvenience compared to changing the format.
Bim
On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
> Benefits of indicating file types, )ellaborating on what´s already been stated).
> Users, particularly users with disabilities, may need to open files in
> "unusual" applications for maximum accessibility (say, they would
> always want to use AdobeReader rather than opening a PDF document in
> the browser). By indicating the filetype on the link you give them an
> opportunity to take the appropriate action, such as right click and
> save the file rather than opening it.
> Yes, users can configure their own workstations or mobile devices to
> always open a certain filetype in a certain application, but users may
> not always be using their own workstations or devices when browsing
> the internet.
> For people with disabilities this is a very important usability issue.
>
>
> Not indicating that a link points to a filetype cannot be called under
> a WCAG violation, as far as I can see, (and I have tried) unless this
> information is not available visually.
> If this info is available visually (e.g. by including an icon as a CSS
> .background image), it would, however, be a violation of WCAG SC 1.1.1
> not to provide that info in some other way.
> Cheers
>
>
>
> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>> Benefits for indicating the type apply to people with motor,
>>> cognitive, and visual impairments. Traversing a link that is not
>>> the intended link can have more serious consequences for people with
>>> disabilities because they have to return to where they were. An
>>> argument can also be made from mobile where large documents can take
>>> a long time to download or cause the user to incur fees for data usage.
>>>
>>> Jonathan
>> Benefits for users who need to keep their rates in mind (mobile
>> users) and those who know whether or not they even have an
>> application available that can open it. For example, if I knew I
>> wanted to avoid .pdf files because I have a crap phone, I now have
>> the knowledge to stay away.
>>
>> I consider it a usability issue.
>> _mallory
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
>
From: Bim Egan
Date: Wed, Oct 22 2014 7:22AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
Andrew took exception to statements I made in my last email, but my
observations are based only on experience as a screen reader user. I was
wrong in one part, only Word documents opened within Internet explorer
give screen readers difficulty in reproducing a correct reading flow.
I've rechecked my statements on the difficulties in returning to the
previous page, including using the Escape key, as Andrew suggested, but
it didn't seem to help. The only way I found to get keyboard focus into
the toolbar was to hold down and release the Alt key. This is
counter-intuitive, the normal action is to hold down the Alt key while
pressing the letter key associated with the required menu, (Alt_F opens
the file menu).
However, once the focus was in the toolbar, I couldn't get it out again
to return to reading the document. The normal action, pressing the
Escape key, didn't work.
The best experience for screen reader and keyboard only users is to read
alternative formats in their native applications. This underpins my
personal view that identifying changes of format within link text is as
important as notifying the user when a new window will open.
Bim
On 21/10/2014 15:08, Andrew Kirkpatrick wrote:
> Bim wrote the following, but there are a few inaccurate statements:
>
> As Birkir said, disabled people may need to save files rather than have them open up within a browser "shell". For screen reader users the reason is that there's little accessibility support in the Adobe Reader and MS Office "shells" produced by Internet Explorer. The reading flow is often broken, it's not possible to get a list of links or headings, etc.
> These "shells" also make it nearly impossible for keyboard only users (including screen reader users), to use keyboard navigation to either
> return to the previous page or navigate between open browser tabs.
> The toolbar is also changed, it's neither the same as the native application, nor the originating browser toolbar.
>
> For Adobe Reader in IE the reading flow matches what you get in Reader on its own. Of course, if the PDF is incorrectly tagged then the reader order may be incorrect, but that is an authoring issue rather than a technology issue.
> Lists and headers read correctly when viewing a PDF in IE with Reader.
> I can move from the PDF document to another tab from the keyboard, but usually need to hit escape to extract the focus from the object within the PDF that it is currently on first.
> Reader doesn't change the toolbar in IE, but does add a toolbar specific to Reader, and this is independently keyboard navigable.
>
> In short, I take exception to the statement that there is little accessibility support in the Reader plug in for IE.
>
> AWK
>
>
>
>
>
> On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
>> Benefits of indicating file types, )ellaborating on what´s already been stated).
>> Users, particularly users with disabilities, may need to open files in
>> "unusual" applications for maximum accessibility (say, they would
>> always want to use AdobeReader rather than opening a PDF document in
>> the browser). By indicating the filetype on the link you give them an
>> opportunity to take the appropriate action, such as right click and
>> save the file rather than opening it.
>> Yes, users can configure their own workstations or mobile devices to
>> always open a certain filetype in a certain application, but users may
>> not always be using their own workstations or devices when browsing
>> the internet.
>> For people with disabilities this is a very important usability issue.
>>
>>
>> Not indicating that a link points to a filetype cannot be called under
>> a WCAG violation, as far as I can see, (and I have tried) unless this
>> information is not available visually.
>> If this info is available visually (e.g. by including an icon as a CSS
>> .background image), it would, however, be a violation of WCAG SC 1.1.1
>> not to provide that info in some other way.
>> Cheers
>>
>>
>>
>> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>>> Benefits for indicating the type apply to people with motor,
>>>> cognitive, and visual impairments. Traversing a link that is not
>>>> the intended link can have more serious consequences for people with
>>>> disabilities because they have to return to where they were. An
>>>> argument can also be made from mobile where large documents can take
>>>> a long time to download or cause the user to incur fees for data usage.
>>>>
>>>> Jonathan
>>> Benefits for users who need to keep their rates in mind (mobile
>>> users) and those who know whether or not they even have an
>>> application available that can open it. For example, if I knew I
>>> wanted to avoid .pdf files because I have a crap phone, I now have
>>> the knowledge to stay away.
>>>
>>> I consider it a usability issue.
>>> _mallory
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>>
> > > > > >
From: Don Mauck
Date: Wed, Oct 22 2014 7:29AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
Bim --
The one suggestion I might give regarding getting back out of the toolbar and into the document is to try a CTRL+F6, then hit the tab key usually three or four times, see if that works. This has always worked for me when I have any screen reader that seems to lose focus. I don't know if that's what's happening here, but it's just a thought.
-----Original Message-----
From: Bim Egan [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, October 22, 2014 7:23 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
Andrew took exception to statements I made in my last email, but my observations are based only on experience as a screen reader user. I was wrong in one part, only Word documents opened within Internet explorer give screen readers difficulty in reproducing a correct reading flow.
I've rechecked my statements on the difficulties in returning to the previous page, including using the Escape key, as Andrew suggested, but it didn't seem to help. The only way I found to get keyboard focus into the toolbar was to hold down and release the Alt key. This is counter-intuitive, the normal action is to hold down the Alt key while pressing the letter key associated with the required menu, (Alt_F opens the file menu).
However, once the focus was in the toolbar, I couldn't get it out again to return to reading the document. The normal action, pressing the Escape key, didn't work.
The best experience for screen reader and keyboard only users is to read alternative formats in their native applications. This underpins my personal view that identifying changes of format within link text is as important as notifying the user when a new window will open.
Bim
On 21/10/2014 15:08, Andrew Kirkpatrick wrote:
> Bim wrote the following, but there are a few inaccurate statements:
>
> As Birkir said, disabled people may need to save files rather than have them open up within a browser "shell". For screen reader users the reason is that there's little accessibility support in the Adobe Reader and MS Office "shells" produced by Internet Explorer. The reading flow is often broken, it's not possible to get a list of links or headings, etc.
> These "shells" also make it nearly impossible for keyboard only users
> (including screen reader users), to use keyboard navigation to either return to the previous page or navigate between open browser tabs.
> The toolbar is also changed, it's neither the same as the native application, nor the originating browser toolbar.
>
> For Adobe Reader in IE the reading flow matches what you get in Reader on its own. Of course, if the PDF is incorrectly tagged then the reader order may be incorrect, but that is an authoring issue rather than a technology issue.
> Lists and headers read correctly when viewing a PDF in IE with Reader.
> I can move from the PDF document to another tab from the keyboard, but usually need to hit escape to extract the focus from the object within the PDF that it is currently on first.
> Reader doesn't change the toolbar in IE, but does add a toolbar specific to Reader, and this is independently keyboard navigable.
>
> In short, I take exception to the statement that there is little accessibility support in the Reader plug in for IE.
>
> AWK
>
>
>
>
>
> On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
>> Benefits of indicating file types, )ellaborating on what´s already been stated).
>> Users, particularly users with disabilities, may need to open files
>> in "unusual" applications for maximum accessibility (say, they would
>> always want to use AdobeReader rather than opening a PDF document in
>> the browser). By indicating the filetype on the link you give them an
>> opportunity to take the appropriate action, such as right click and
>> save the file rather than opening it.
>> Yes, users can configure their own workstations or mobile devices to
>> always open a certain filetype in a certain application, but users
>> may not always be using their own workstations or devices when
>> browsing the internet.
>> For people with disabilities this is a very important usability issue.
>>
>>
>> Not indicating that a link points to a filetype cannot be called
>> under a WCAG violation, as far as I can see, (and I have tried)
>> unless this information is not available visually.
>> If this info is available visually (e.g. by including an icon as a
>> CSS .background image), it would, however, be a violation of WCAG SC
>> 1.1.1 not to provide that info in some other way.
>> Cheers
>>
>>
>>
>> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>>> Benefits for indicating the type apply to people with motor,
>>>> cognitive, and visual impairments. Traversing a link that is not
>>>> the intended link can have more serious consequences for people
>>>> with disabilities because they have to return to where they were.
>>>> An argument can also be made from mobile where large documents can
>>>> take a long time to download or cause the user to incur fees for data usage.
>>>>
>>>> Jonathan
>>> Benefits for users who need to keep their rates in mind (mobile
>>> users) and those who know whether or not they even have an
>>> application available that can open it. For example, if I knew I
>>> wanted to avoid .pdf files because I have a crap phone, I now have
>>> the knowledge to stay away.
>>>
>>> I consider it a usability issue.
>>> _mallory
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>>
> > > list messages to = EMAIL ADDRESS REMOVED =
> > > list messages to = EMAIL ADDRESS REMOVED =
>
From: Bim Egan
Date: Wed, Oct 22 2014 8:09AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
Thanks for that suggestion Don, I did try F6, which works for web pages,
but in the version of Internet Explorer rendering other formats, I ended
up trapped in the address bar. I'll try it in combination with the
Control key.
Bim
On 22/10/2014 14:29, Don Mauck wrote:
> Bim --
> The one suggestion I might give regarding getting back out of the toolbar and into the document is to try a CTRL+F6, then hit the tab key usually three or four times, see if that works. This has always worked for me when I have any screen reader that seems to lose focus. I don't know if that's what's happening here, but it's just a thought.
>
> -----Original Message-----
> From: Bim Egan [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, October 22, 2014 7:23 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
>
> Andrew took exception to statements I made in my last email, but my observations are based only on experience as a screen reader user. I was wrong in one part, only Word documents opened within Internet explorer give screen readers difficulty in reproducing a correct reading flow.
>
> I've rechecked my statements on the difficulties in returning to the previous page, including using the Escape key, as Andrew suggested, but it didn't seem to help. The only way I found to get keyboard focus into the toolbar was to hold down and release the Alt key. This is counter-intuitive, the normal action is to hold down the Alt key while pressing the letter key associated with the required menu, (Alt_F opens the file menu).
>
> However, once the focus was in the toolbar, I couldn't get it out again to return to reading the document. The normal action, pressing the Escape key, didn't work.
>
> The best experience for screen reader and keyboard only users is to read alternative formats in their native applications. This underpins my personal view that identifying changes of format within link text is as important as notifying the user when a new window will open.
>
> Bim
>
>
>
> On 21/10/2014 15:08, Andrew Kirkpatrick wrote:
>> Bim wrote the following, but there are a few inaccurate statements:
>>
>> As Birkir said, disabled people may need to save files rather than have them open up within a browser "shell". For screen reader users the reason is that there's little accessibility support in the Adobe Reader and MS Office "shells" produced by Internet Explorer. The reading flow is often broken, it's not possible to get a list of links or headings, etc.
>> These "shells" also make it nearly impossible for keyboard only users
>> (including screen reader users), to use keyboard navigation to either return to the previous page or navigate between open browser tabs.
>> The toolbar is also changed, it's neither the same as the native application, nor the originating browser toolbar.
>>
>> For Adobe Reader in IE the reading flow matches what you get in Reader on its own. Of course, if the PDF is incorrectly tagged then the reader order may be incorrect, but that is an authoring issue rather than a technology issue.
>> Lists and headers read correctly when viewing a PDF in IE with Reader.
>> I can move from the PDF document to another tab from the keyboard, but usually need to hit escape to extract the focus from the object within the PDF that it is currently on first.
>> Reader doesn't change the toolbar in IE, but does add a toolbar specific to Reader, and this is independently keyboard navigable.
>>
>> In short, I take exception to the statement that there is little accessibility support in the Reader plug in for IE.
>>
>> AWK
>>
>>
>>
>>
>>
>> On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
>>> Benefits of indicating file types, )ellaborating on what´s already been stated).
>>> Users, particularly users with disabilities, may need to open files
>>> in "unusual" applications for maximum accessibility (say, they would
>>> always want to use AdobeReader rather than opening a PDF document in
>>> the browser). By indicating the filetype on the link you give them an
>>> opportunity to take the appropriate action, such as right click and
>>> save the file rather than opening it.
>>> Yes, users can configure their own workstations or mobile devices to
>>> always open a certain filetype in a certain application, but users
>>> may not always be using their own workstations or devices when
>>> browsing the internet.
>>> For people with disabilities this is a very important usability issue.
>>>
>>>
>>> Not indicating that a link points to a filetype cannot be called
>>> under a WCAG violation, as far as I can see, (and I have tried)
>>> unless this information is not available visually.
>>> If this info is available visually (e.g. by including an icon as a
>>> CSS .background image), it would, however, be a violation of WCAG SC
>>> 1.1.1 not to provide that info in some other way.
>>> Cheers
>>>
>>>
>>>
>>> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>>>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>>>> Benefits for indicating the type apply to people with motor,
>>>>> cognitive, and visual impairments. Traversing a link that is not
>>>>> the intended link can have more serious consequences for people
>>>>> with disabilities because they have to return to where they were.
>>>>> An argument can also be made from mobile where large documents can
>>>>> take a long time to download or cause the user to incur fees for data usage.
>>>>>
>>>>> Jonathan
>>>> Benefits for users who need to keep their rates in mind (mobile
>>>> users) and those who know whether or not they even have an
>>>> application available that can open it. For example, if I knew I
>>>> wanted to avoid .pdf files because I have a crap phone, I now have
>>>> the knowledge to stay away.
>>>>
>>>> I consider it a usability issue.
>>>> _mallory
>>>> >>>> >>>> list messages to = EMAIL ADDRESS REMOVED =
>>>>
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
> > > > > >
From: Birkir R. Gunnarsson
Date: Wed, Oct 22 2014 10:56AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
The only way I have found to get out of a PDF document in IE at least
is to press alt-f4 and then select to "close current tab" button.
ctrl-f4 does not work for me when the browser is showing a PDF
document, it works fine for a webpage.
I know we are straying into specifics here, but the point is that
users need to open native applications to read most non-html files.
However browsers increasingly provide plug-ins for viewing these files
by default, and often those are not accessible and can even cause
serious accessibility issues.
Users can become trapped in the browser and end up giving up on the
page altogether
I wish indicating that a link points to a file was at least a AA
requirement, because I think this causes a lot more confusion for
users than when a page opens in a separate window (after all the
screen readers themselves could usually announce this if they see a
link with target="_blank", if the opening is done via Javascript they
would not announce this, the same applies to a file download link to a
degree).
But bottomline is that WCAG does not cover that scenario within any of
its A or AA requirements, not even in the most creative intrpretations
I have been able to come up with (and when I work with clients I try
to be pragmatic rather than creative, personally I sometimes still try
to see how I could call something under WCAG A or AA success criterion
if I really wanted to).
Cheers
-Birkir
On 10/22/14, Bim Egan < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks for that suggestion Don, I did try F6, which works for web pages,
> but in the version of Internet Explorer rendering other formats, I ended
> up trapped in the address bar. I'll try it in combination with the
> Control key.
>
> Bim
>
>
> On 22/10/2014 14:29, Don Mauck wrote:
>> Bim --
>> The one suggestion I might give regarding getting back out of the toolbar
>> and into the document is to try a CTRL+F6, then hit the tab key usually
>> three or four times, see if that works. This has always worked for me
>> when I have any screen reader that seems to lose focus. I don't know if
>> that's what's happening here, but it's just a thought.
>>
>> -----Original Message-----
>> From: Bim Egan [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Wednesday, October 22, 2014 7:23 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Current best practice/standard/guideline for linking
>> to non-html files?
>>
>> Andrew took exception to statements I made in my last email, but my
>> observations are based only on experience as a screen reader user. I was
>> wrong in one part, only Word documents opened within Internet explorer
>> give screen readers difficulty in reproducing a correct reading flow.
>>
>> I've rechecked my statements on the difficulties in returning to the
>> previous page, including using the Escape key, as Andrew suggested, but
>> it didn't seem to help. The only way I found to get keyboard focus into
>> the toolbar was to hold down and release the Alt key. This is
>> counter-intuitive, the normal action is to hold down the Alt key while
>> pressing the letter key associated with the required menu, (Alt_F opens
>> the file menu).
>>
>> However, once the focus was in the toolbar, I couldn't get it out again to
>> return to reading the document. The normal action, pressing the Escape
>> key, didn't work.
>>
>> The best experience for screen reader and keyboard only users is to read
>> alternative formats in their native applications. This underpins my
>> personal view that identifying changes of format within link text is as
>> important as notifying the user when a new window will open.
>>
>> Bim
>>
>>
>>
>> On 21/10/2014 15:08, Andrew Kirkpatrick wrote:
>>> Bim wrote the following, but there are a few inaccurate statements:
>>>
>>> As Birkir said, disabled people may need to save files rather than have
>>> them open up within a browser "shell". For screen reader users the
>>> reason is that there's little accessibility support in the Adobe Reader
>>> and MS Office "shells" produced by Internet Explorer. The reading flow is
>>> often broken, it's not possible to get a list of links or headings, etc.
>>> These "shells" also make it nearly impossible for keyboard only users
>>> (including screen reader users), to use keyboard navigation to either
>>> return to the previous page or navigate between open browser tabs.
>>> The toolbar is also changed, it's neither the same as the native
>>> application, nor the originating browser toolbar.
>>>
>>> For Adobe Reader in IE the reading flow matches what you get in Reader on
>>> its own. Of course, if the PDF is incorrectly tagged then the reader
>>> order may be incorrect, but that is an authoring issue rather than a
>>> technology issue.
>>> Lists and headers read correctly when viewing a PDF in IE with Reader.
>>> I can move from the PDF document to another tab from the keyboard, but
>>> usually need to hit escape to extract the focus from the object within
>>> the PDF that it is currently on first.
>>> Reader doesn't change the toolbar in IE, but does add a toolbar specific
>>> to Reader, and this is independently keyboard navigable.
>>>
>>> In short, I take exception to the statement that there is little
>>> accessibility support in the Reader plug in for IE.
>>>
>>> AWK
>>>
>>>
>>>
>>>
>>>
>>> On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
>>>> Benefits of indicating file types, )ellaborating on what´s already been
>>>> stated).
>>>> Users, particularly users with disabilities, may need to open files
>>>> in "unusual" applications for maximum accessibility (say, they would
>>>> always want to use AdobeReader rather than opening a PDF document in
>>>> the browser). By indicating the filetype on the link you give them an
>>>> opportunity to take the appropriate action, such as right click and
>>>> save the file rather than opening it.
>>>> Yes, users can configure their own workstations or mobile devices to
>>>> always open a certain filetype in a certain application, but users
>>>> may not always be using their own workstations or devices when
>>>> browsing the internet.
>>>> For people with disabilities this is a very important usability issue.
>>>>
>>>>
>>>> Not indicating that a link points to a filetype cannot be called
>>>> under a WCAG violation, as far as I can see, (and I have tried)
>>>> unless this information is not available visually.
>>>> If this info is available visually (e.g. by including an icon as a
>>>> CSS .background image), it would, however, be a violation of WCAG SC
>>>> 1.1.1 not to provide that info in some other way.
>>>> Cheers
>>>>
>>>>
>>>>
>>>> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>>>>> Benefits for indicating the type apply to people with motor,
>>>>>> cognitive, and visual impairments. Traversing a link that is not
>>>>>> the intended link can have more serious consequences for people
>>>>>> with disabilities because they have to return to where they were.
>>>>>> An argument can also be made from mobile where large documents can
>>>>>> take a long time to download or cause the user to incur fees for data
>>>>>> usage.
>>>>>>
>>>>>> Jonathan
>>>>> Benefits for users who need to keep their rates in mind (mobile
>>>>> users) and those who know whether or not they even have an
>>>>> application available that can open it. For example, if I knew I
>>>>> wanted to avoid .pdf files because I have a crap phone, I now have
>>>>> the knowledge to stay away.
>>>>>
>>>>> I consider it a usability issue.
>>>>> _mallory
>>>>> >>>>> >>>>> list messages to = EMAIL ADDRESS REMOVED =
>>>>>
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>>
>> >> >> messages to = EMAIL ADDRESS REMOVED =
>> >> >> >>
>
> > > >
--
Work hard. Have fun. Make history.
From: Angela French
Date: Wed, Oct 22 2014 11:42AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
Thank you for all the great responses so far!
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, October 22, 2014 9:56 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
The only way I have found to get out of a PDF document in IE at least is to press alt-f4 and then select to "close current tab" button.
ctrl-f4 does not work for me when the browser is showing a PDF document, it works fine for a webpage.
I know we are straying into specifics here, but the point is that users need to open native applications to read most non-html files.
However browsers increasingly provide plug-ins for viewing these files by default, and often those are not accessible and can even cause serious accessibility issues.
Users can become trapped in the browser and end up giving up on the page altogether I wish indicating that a link points to a file was at least a AA requirement, because I think this causes a lot more confusion for users than when a page opens in a separate window (after all the screen readers themselves could usually announce this if they see a link with target="_blank", if the opening is done via Javascript they would not announce this, the same applies to a file download link to a degree).
But bottomline is that WCAG does not cover that scenario within any of its A or AA requirements, not even in the most creative intrpretations I have been able to come up with (and when I work with clients I try to be pragmatic rather than creative, personally I sometimes still try to see how I could call something under WCAG A or AA success criterion if I really wanted to).
Cheers
-Birkir
On 10/22/14, Bim Egan < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks for that suggestion Don, I did try F6, which works for web
> pages, but in the version of Internet Explorer rendering other formats, I ended
> up trapped in the address bar. I'll try it in combination with the
> Control key.
>
> Bim
>
>
> On 22/10/2014 14:29, Don Mauck wrote:
>> Bim --
>> The one suggestion I might give regarding getting back out of the
>> toolbar and into the document is to try a CTRL+F6, then hit the tab
>> key usually three or four times, see if that works. This has always
>> worked for me when I have any screen reader that seems to lose focus.
>> I don't know if that's what's happening here, but it's just a thought.
>>
>> -----Original Message-----
>> From: Bim Egan [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Wednesday, October 22, 2014 7:23 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Current best practice/standard/guideline for
>> linking to non-html files?
>>
>> Andrew took exception to statements I made in my last email, but my
>> observations are based only on experience as a screen reader user. I
>> was wrong in one part, only Word documents opened within Internet
>> explorer give screen readers difficulty in reproducing a correct reading flow.
>>
>> I've rechecked my statements on the difficulties in returning to the
>> previous page, including using the Escape key, as Andrew suggested,
>> but it didn't seem to help. The only way I found to get keyboard
>> focus into the toolbar was to hold down and release the Alt key. This
>> is counter-intuitive, the normal action is to hold down the Alt key
>> while pressing the letter key associated with the required menu,
>> (Alt_F opens the file menu).
>>
>> However, once the focus was in the toolbar, I couldn't get it out
>> again to return to reading the document. The normal action, pressing
>> the Escape key, didn't work.
>>
>> The best experience for screen reader and keyboard only users is to
>> read alternative formats in their native applications. This underpins
>> my personal view that identifying changes of format within link text
>> is as important as notifying the user when a new window will open.
>>
>> Bim
>>
>>
>>
>> On 21/10/2014 15:08, Andrew Kirkpatrick wrote:
>>> Bim wrote the following, but there are a few inaccurate statements:
>>>
>>> As Birkir said, disabled people may need to save files rather than
>>> have them open up within a browser "shell". For screen reader users
>>> the reason is that there's little accessibility support in the Adobe
>>> Reader and MS Office "shells" produced by Internet Explorer. The
>>> reading flow is often broken, it's not possible to get a list of links or headings, etc.
>>> These "shells" also make it nearly impossible for keyboard only
>>> users (including screen reader users), to use keyboard navigation to
>>> either return to the previous page or navigate between open browser tabs.
>>> The toolbar is also changed, it's neither the same as the native
>>> application, nor the originating browser toolbar.
>>>
>>> For Adobe Reader in IE the reading flow matches what you get in
>>> Reader on its own. Of course, if the PDF is incorrectly tagged then
>>> the reader order may be incorrect, but that is an authoring issue
>>> rather than a technology issue.
>>> Lists and headers read correctly when viewing a PDF in IE with Reader.
>>> I can move from the PDF document to another tab from the keyboard,
>>> but usually need to hit escape to extract the focus from the object
>>> within the PDF that it is currently on first.
>>> Reader doesn't change the toolbar in IE, but does add a toolbar
>>> specific to Reader, and this is independently keyboard navigable.
>>>
>>> In short, I take exception to the statement that there is little
>>> accessibility support in the Reader plug in for IE.
>>>
>>> AWK
>>>
>>>
>>>
>>>
>>>
>>> On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
>>>> Benefits of indicating file types, )ellaborating on what´s already
>>>> been stated).
>>>> Users, particularly users with disabilities, may need to open files
>>>> in "unusual" applications for maximum accessibility (say, they
>>>> would always want to use AdobeReader rather than opening a PDF
>>>> document in the browser). By indicating the filetype on the link
>>>> you give them an opportunity to take the appropriate action, such
>>>> as right click and save the file rather than opening it.
>>>> Yes, users can configure their own workstations or mobile devices
>>>> to always open a certain filetype in a certain application, but
>>>> users may not always be using their own workstations or devices
>>>> when browsing the internet.
>>>> For people with disabilities this is a very important usability issue.
>>>>
>>>>
>>>> Not indicating that a link points to a filetype cannot be called
>>>> under a WCAG violation, as far as I can see, (and I have tried)
>>>> unless this information is not available visually.
>>>> If this info is available visually (e.g. by including an icon as a
>>>> CSS .background image), it would, however, be a violation of WCAG
>>>> SC
>>>> 1.1.1 not to provide that info in some other way.
>>>> Cheers
>>>>
>>>>
>>>>
>>>> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>>>>> Benefits for indicating the type apply to people with motor,
>>>>>> cognitive, and visual impairments. Traversing a link that is not
>>>>>> the intended link can have more serious consequences for people
>>>>>> with disabilities because they have to return to where they were.
>>>>>> An argument can also be made from mobile where large documents
>>>>>> can take a long time to download or cause the user to incur fees
>>>>>> for data usage.
>>>>>>
>>>>>> Jonathan
>>>>> Benefits for users who need to keep their rates in mind (mobile
>>>>> users) and those who know whether or not they even have an
>>>>> application available that can open it. For example, if I knew I
>>>>> wanted to avoid .pdf files because I have a crap phone, I now have
>>>>> the knowledge to stay away.
>>>>>
>>>>> I consider it a usability issue.
>>>>> _mallory
>>>>> >>>>> >>>>> list messages to = EMAIL ADDRESS REMOVED =
>>>>>
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>>
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
>
> > > list messages to = EMAIL ADDRESS REMOVED =
>
--
Work hard. Have fun. Make history.
From: Andrew Kirkpatrick
Date: Wed, Oct 22 2014 2:09PM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
I misspoke about using the escape key. Using escape is useful when you are in a form and need to restore keyboard support for scrolling the page.
For JAWS users, you can get out of the PDF document by using the same shortcut you may use to get the address bar (alt+d). Once you are there, ctrl+tab will allow you to switch tabs, and then when you return to the PDF document from the other resource JAWS does remember where in the PDF document you were and resumes reading from that point.
To get to the Reader toolbar, hit shift+f8 - this moves focus there and opens the toolbar. To return, hit f8 and the focus returns to the document.
Hope this helps.
AWK
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Angela French
Sent: Wednesday, October 22, 2014 1:42 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
Thank you for all the great responses so far!
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, October 22, 2014 9:56 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
The only way I have found to get out of a PDF document in IE at least is to press alt-f4 and then select to "close current tab" button.
ctrl-f4 does not work for me when the browser is showing a PDF document, it works fine for a webpage.
I know we are straying into specifics here, but the point is that users need to open native applications to read most non-html files.
However browsers increasingly provide plug-ins for viewing these files by default, and often those are not accessible and can even cause serious accessibility issues.
Users can become trapped in the browser and end up giving up on the page altogether I wish indicating that a link points to a file was at least a AA requirement, because I think this causes a lot more confusion for users than when a page opens in a separate window (after all the screen readers themselves could usually announce this if they see a link with target="_blank", if the opening is done via Javascript they would not announce this, the same applies to a file download link to a degree).
But bottomline is that WCAG does not cover that scenario within any of its A or AA requirements, not even in the most creative intrpretations I have been able to come up with (and when I work with clients I try to be pragmatic rather than creative, personally I sometimes still try to see how I could call something under WCAG A or AA success criterion if I really wanted to).
Cheers
-Birkir
On 10/22/14, Bim Egan < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks for that suggestion Don, I did try F6, which works for web
> pages, but in the version of Internet Explorer rendering other formats, I ended
> up trapped in the address bar. I'll try it in combination with the
> Control key.
>
> Bim
>
>
> On 22/10/2014 14:29, Don Mauck wrote:
>> Bim --
>> The one suggestion I might give regarding getting back out of the
>> toolbar and into the document is to try a CTRL+F6, then hit the tab
>> key usually three or four times, see if that works. This has always
>> worked for me when I have any screen reader that seems to lose focus.
>> I don't know if that's what's happening here, but it's just a thought.
>>
>> -----Original Message-----
>> From: Bim Egan [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Wednesday, October 22, 2014 7:23 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Current best practice/standard/guideline for
>> linking to non-html files?
>>
>> Andrew took exception to statements I made in my last email, but my
>> observations are based only on experience as a screen reader user. I
>> was wrong in one part, only Word documents opened within Internet
>> explorer give screen readers difficulty in reproducing a correct reading flow.
>>
>> I've rechecked my statements on the difficulties in returning to the
>> previous page, including using the Escape key, as Andrew suggested,
>> but it didn't seem to help. The only way I found to get keyboard
>> focus into the toolbar was to hold down and release the Alt key. This
>> is counter-intuitive, the normal action is to hold down the Alt key
>> while pressing the letter key associated with the required menu,
>> (Alt_F opens the file menu).
>>
>> However, once the focus was in the toolbar, I couldn't get it out
>> again to return to reading the document. The normal action, pressing
>> the Escape key, didn't work.
>>
>> The best experience for screen reader and keyboard only users is to
>> read alternative formats in their native applications. This underpins
>> my personal view that identifying changes of format within link text
>> is as important as notifying the user when a new window will open.
>>
>> Bim
>>
>>
>>
>> On 21/10/2014 15:08, Andrew Kirkpatrick wrote:
>>> Bim wrote the following, but there are a few inaccurate statements:
>>>
>>> As Birkir said, disabled people may need to save files rather than
>>> have them open up within a browser "shell". For screen reader users
>>> the reason is that there's little accessibility support in the Adobe
>>> Reader and MS Office "shells" produced by Internet Explorer. The
>>> reading flow is often broken, it's not possible to get a list of links or headings, etc.
>>> These "shells" also make it nearly impossible for keyboard only
>>> users (including screen reader users), to use keyboard navigation to
>>> either return to the previous page or navigate between open browser tabs.
>>> The toolbar is also changed, it's neither the same as the native
>>> application, nor the originating browser toolbar.
>>>
>>> For Adobe Reader in IE the reading flow matches what you get in
>>> Reader on its own. Of course, if the PDF is incorrectly tagged then
>>> the reader order may be incorrect, but that is an authoring issue
>>> rather than a technology issue.
>>> Lists and headers read correctly when viewing a PDF in IE with Reader.
>>> I can move from the PDF document to another tab from the keyboard,
>>> but usually need to hit escape to extract the focus from the object
>>> within the PDF that it is currently on first.
>>> Reader doesn't change the toolbar in IE, but does add a toolbar
>>> specific to Reader, and this is independently keyboard navigable.
>>>
>>> In short, I take exception to the statement that there is little
>>> accessibility support in the Reader plug in for IE.
>>>
>>> AWK
>>>
>>>
>>>
>>>
>>>
>>> On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
>>>> Benefits of indicating file types, )ellaborating on what´s already
>>>> been stated).
>>>> Users, particularly users with disabilities, may need to open files
>>>> in "unusual" applications for maximum accessibility (say, they
>>>> would always want to use AdobeReader rather than opening a PDF
>>>> document in the browser). By indicating the filetype on the link
>>>> you give them an opportunity to take the appropriate action, such
>>>> as right click and save the file rather than opening it.
>>>> Yes, users can configure their own workstations or mobile devices
>>>> to always open a certain filetype in a certain application, but
>>>> users may not always be using their own workstations or devices
>>>> when browsing the internet.
>>>> For people with disabilities this is a very important usability issue.
>>>>
>>>>
>>>> Not indicating that a link points to a filetype cannot be called
>>>> under a WCAG violation, as far as I can see, (and I have tried)
>>>> unless this information is not available visually.
>>>> If this info is available visually (e.g. by including an icon as a
>>>> CSS .background image), it would, however, be a violation of WCAG
>>>> SC
>>>> 1.1.1 not to provide that info in some other way.
>>>> Cheers
>>>>
>>>>
>>>>
>>>> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>>>>> Benefits for indicating the type apply to people with motor,
>>>>>> cognitive, and visual impairments. Traversing a link that is not
>>>>>> the intended link can have more serious consequences for people
>>>>>> with disabilities because they have to return to where they were.
>>>>>> An argument can also be made from mobile where large documents
>>>>>> can take a long time to download or cause the user to incur fees
>>>>>> for data usage.
>>>>>>
>>>>>> Jonathan
>>>>> Benefits for users who need to keep their rates in mind (mobile
>>>>> users) and those who know whether or not they even have an
>>>>> application available that can open it. For example, if I knew I
>>>>> wanted to avoid .pdf files because I have a crap phone, I now have
>>>>> the knowledge to stay away.
>>>>>
>>>>> I consider it a usability issue.
>>>>> _mallory
>>>>> >>>>> >>>>> list messages to = EMAIL ADDRESS REMOVED =
>>>>>
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>>
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
>
> > > list messages to = EMAIL ADDRESS REMOVED =
>
--
Work hard. Have fun. Make history.
From: Bim Egan
Date: Thu, Oct 23 2014 3:50AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | Next message →
Yes, thank you Andrew, all information helps, and those shortcuts do
work. They also highlight that, for people who can't use a mouse or
need a screen reader, there is a real difference in context resulting
from following a link to a web page and following a link to a different
format. Don't you agree?
Bim
On 22/10/2014 21:09, Andrew Kirkpatrick wrote:
> I misspoke about using the escape key. Using escape is useful when you are in a form and need to restore keyboard support for scrolling the page.
>
> For JAWS users, you can get out of the PDF document by using the same shortcut you may use to get the address bar (alt+d). Once you are there, ctrl+tab will allow you to switch tabs, and then when you return to the PDF document from the other resource JAWS does remember where in the PDF document you were and resumes reading from that point.
>
> To get to the Reader toolbar, hit shift+f8 - this moves focus there and opens the toolbar. To return, hit f8 and the focus returns to the document.
>
> Hope this helps.
> AWK
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Angela French
> Sent: Wednesday, October 22, 2014 1:42 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
>
> Thank you for all the great responses so far!
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
> Sent: Wednesday, October 22, 2014 9:56 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
>
> The only way I have found to get out of a PDF document in IE at least is to press alt-f4 and then select to "close current tab" button.
> ctrl-f4 does not work for me when the browser is showing a PDF document, it works fine for a webpage.
> I know we are straying into specifics here, but the point is that users need to open native applications to read most non-html files.
> However browsers increasingly provide plug-ins for viewing these files by default, and often those are not accessible and can even cause serious accessibility issues.
>
> Users can become trapped in the browser and end up giving up on the page altogether I wish indicating that a link points to a file was at least a AA requirement, because I think this causes a lot more confusion for users than when a page opens in a separate window (after all the screen readers themselves could usually announce this if they see a link with target="_blank", if the opening is done via Javascript they would not announce this, the same applies to a file download link to a degree).
> But bottomline is that WCAG does not cover that scenario within any of its A or AA requirements, not even in the most creative intrpretations I have been able to come up with (and when I work with clients I try to be pragmatic rather than creative, personally I sometimes still try to see how I could call something under WCAG A or AA success criterion if I really wanted to).
>
> Cheers
> -Birkir
>
>
> On 10/22/14, Bim Egan < = EMAIL ADDRESS REMOVED = > wrote:
>> Thanks for that suggestion Don, I did try F6, which works for web
>> pages, but in the version of Internet Explorer rendering other formats, I ended
>> up trapped in the address bar. I'll try it in combination with the
>> Control key.
>>
>> Bim
>>
>>
>> On 22/10/2014 14:29, Don Mauck wrote:
>>> Bim --
>>> The one suggestion I might give regarding getting back out of the
>>> toolbar and into the document is to try a CTRL+F6, then hit the tab
>>> key usually three or four times, see if that works. This has always
>>> worked for me when I have any screen reader that seems to lose focus.
>>> I don't know if that's what's happening here, but it's just a thought.
>>>
>>> -----Original Message-----
>>> From: Bim Egan [mailto: = EMAIL ADDRESS REMOVED = ]
>>> Sent: Wednesday, October 22, 2014 7:23 AM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Current best practice/standard/guideline for
>>> linking to non-html files?
>>>
>>> Andrew took exception to statements I made in my last email, but my
>>> observations are based only on experience as a screen reader user. I
>>> was wrong in one part, only Word documents opened within Internet
>>> explorer give screen readers difficulty in reproducing a correct reading flow.
>>>
>>> I've rechecked my statements on the difficulties in returning to the
>>> previous page, including using the Escape key, as Andrew suggested,
>>> but it didn't seem to help. The only way I found to get keyboard
>>> focus into the toolbar was to hold down and release the Alt key. This
>>> is counter-intuitive, the normal action is to hold down the Alt key
>>> while pressing the letter key associated with the required menu,
>>> (Alt_F opens the file menu).
>>>
>>> However, once the focus was in the toolbar, I couldn't get it out
>>> again to return to reading the document. The normal action, pressing
>>> the Escape key, didn't work.
>>>
>>> The best experience for screen reader and keyboard only users is to
>>> read alternative formats in their native applications. This underpins
>>> my personal view that identifying changes of format within link text
>>> is as important as notifying the user when a new window will open.
>>>
>>> Bim
>>>
>>>
>>>
>>> On 21/10/2014 15:08, Andrew Kirkpatrick wrote:
>>>> Bim wrote the following, but there are a few inaccurate statements:
>>>>
>>>> As Birkir said, disabled people may need to save files rather than
>>>> have them open up within a browser "shell". For screen reader users
>>>> the reason is that there's little accessibility support in the Adobe
>>>> Reader and MS Office "shells" produced by Internet Explorer. The
>>>> reading flow is often broken, it's not possible to get a list of links or headings, etc.
>>>> These "shells" also make it nearly impossible for keyboard only
>>>> users (including screen reader users), to use keyboard navigation to
>>>> either return to the previous page or navigate between open browser tabs.
>>>> The toolbar is also changed, it's neither the same as the native
>>>> application, nor the originating browser toolbar.
>>>>
>>>> For Adobe Reader in IE the reading flow matches what you get in
>>>> Reader on its own. Of course, if the PDF is incorrectly tagged then
>>>> the reader order may be incorrect, but that is an authoring issue
>>>> rather than a technology issue.
>>>> Lists and headers read correctly when viewing a PDF in IE with Reader.
>>>> I can move from the PDF document to another tab from the keyboard,
>>>> but usually need to hit escape to extract the focus from the object
>>>> within the PDF that it is currently on first.
>>>> Reader doesn't change the toolbar in IE, but does add a toolbar
>>>> specific to Reader, and this is independently keyboard navigable.
>>>>
>>>> In short, I take exception to the statement that there is little
>>>> accessibility support in the Reader plug in for IE.
>>>>
>>>> AWK
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
>>>>> Benefits of indicating file types, )ellaborating on what´s already
>>>>> been stated).
>>>>> Users, particularly users with disabilities, may need to open files
>>>>> in "unusual" applications for maximum accessibility (say, they
>>>>> would always want to use AdobeReader rather than opening a PDF
>>>>> document in the browser). By indicating the filetype on the link
>>>>> you give them an opportunity to take the appropriate action, such
>>>>> as right click and save the file rather than opening it.
>>>>> Yes, users can configure their own workstations or mobile devices
>>>>> to always open a certain filetype in a certain application, but
>>>>> users may not always be using their own workstations or devices
>>>>> when browsing the internet.
>>>>> For people with disabilities this is a very important usability issue.
>>>>>
>>>>>
>>>>> Not indicating that a link points to a filetype cannot be called
>>>>> under a WCAG violation, as far as I can see, (and I have tried)
>>>>> unless this information is not available visually.
>>>>> If this info is available visually (e.g. by including an icon as a
>>>>> CSS .background image), it would, however, be a violation of WCAG
>>>>> SC
>>>>> 1.1.1 not to provide that info in some other way.
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>>>>>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>>>>>> Benefits for indicating the type apply to people with motor,
>>>>>>> cognitive, and visual impairments. Traversing a link that is not
>>>>>>> the intended link can have more serious consequences for people
>>>>>>> with disabilities because they have to return to where they were.
>>>>>>> An argument can also be made from mobile where large documents
>>>>>>> can take a long time to download or cause the user to incur fees
>>>>>>> for data usage.
>>>>>>>
>>>>>>> Jonathan
>>>>>> Benefits for users who need to keep their rates in mind (mobile
>>>>>> users) and those who know whether or not they even have an
>>>>>> application available that can open it. For example, if I knew I
>>>>>> wanted to avoid .pdf files because I have a crap phone, I now have
>>>>>> the knowledge to stay away.
>>>>>>
>>>>>> I consider it a usability issue.
>>>>>> _mallory
>>>>>> >>>>>> >>>>>> list messages to = EMAIL ADDRESS REMOVED =
>>>>>>
>>>> >>>> >>>> list messages to = EMAIL ADDRESS REMOVED =
>>>> >>>> >>>> list messages to = EMAIL ADDRESS REMOVED =
>>>>
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>>
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
>
> --
> Work hard. Have fun. Make history.
> > > > > >
From: Andrew Kirkpatrick
Date: Thu, Oct 23 2014 7:09AM
Subject: Re: Current best practice/standard/guideline for linking to non-html files?
← Previous message | No next message
If you follow a link to anything, including a different web page or a PDF document there is a difference in context. I'm not sure what you mean by a "real difference in context".
A user needs to understand their environment in order to be able to adeptly maneuver. Users can select a preference in Reader so that PDF documents will be opened in the standalone application instead of within the browser, so this surely helps people ensure that the environment is the one that they prefer. This setting doesn't affect the situation that Jon raised where the PDF document is provided within an HTML page, but it will for much of the PDF based content that people interact with.
I cannot argue that many people like to know if a PDF document is going to open when clicking on a link, and as a result when we link to PDF documents on the pages my team controls we make an effort to ensure that this will be obvious. However, I believe that this represents a usability improvement rather than an accessibility improvement, as all of the content is available to users if they view the document within the browser and users have a way to change that behavior.
AWK
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bim Egan
Sent: Thursday, October 23, 2014 5:51 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
Yes, thank you Andrew, all information helps, and those shortcuts do work. They also highlight that, for people who can't use a mouse or need a screen reader, there is a real difference in context resulting from following a link to a web page and following a link to a different format. Don't you agree?
Bim
On 22/10/2014 21:09, Andrew Kirkpatrick wrote:
> I misspoke about using the escape key. Using escape is useful when you are in a form and need to restore keyboard support for scrolling the page.
>
> For JAWS users, you can get out of the PDF document by using the same shortcut you may use to get the address bar (alt+d). Once you are there, ctrl+tab will allow you to switch tabs, and then when you return to the PDF document from the other resource JAWS does remember where in the PDF document you were and resumes reading from that point.
>
> To get to the Reader toolbar, hit shift+f8 - this moves focus there and opens the toolbar. To return, hit f8 and the focus returns to the document.
>
> Hope this helps.
> AWK
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Angela French
> Sent: Wednesday, October 22, 2014 1:42 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
>
> Thank you for all the great responses so far!
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
> Sent: Wednesday, October 22, 2014 9:56 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Current best practice/standard/guideline for linking to non-html files?
>
> The only way I have found to get out of a PDF document in IE at least is to press alt-f4 and then select to "close current tab" button.
> ctrl-f4 does not work for me when the browser is showing a PDF document, it works fine for a webpage.
> I know we are straying into specifics here, but the point is that users need to open native applications to read most non-html files.
> However browsers increasingly provide plug-ins for viewing these files by default, and often those are not accessible and can even cause serious accessibility issues.
>
> Users can become trapped in the browser and end up giving up on the page altogether I wish indicating that a link points to a file was at least a AA requirement, because I think this causes a lot more confusion for users than when a page opens in a separate window (after all the screen readers themselves could usually announce this if they see a link with target="_blank", if the opening is done via Javascript they would not announce this, the same applies to a file download link to a degree).
> But bottomline is that WCAG does not cover that scenario within any of its A or AA requirements, not even in the most creative intrpretations I have been able to come up with (and when I work with clients I try to be pragmatic rather than creative, personally I sometimes still try to see how I could call something under WCAG A or AA success criterion if I really wanted to).
>
> Cheers
> -Birkir
>
>
> On 10/22/14, Bim Egan < = EMAIL ADDRESS REMOVED = > wrote:
>> Thanks for that suggestion Don, I did try F6, which works for web
>> pages, but in the version of Internet Explorer rendering other formats, I ended
>> up trapped in the address bar. I'll try it in combination with the
>> Control key.
>>
>> Bim
>>
>>
>> On 22/10/2014 14:29, Don Mauck wrote:
>>> Bim --
>>> The one suggestion I might give regarding getting back out of the
>>> toolbar and into the document is to try a CTRL+F6, then hit the tab
>>> key usually three or four times, see if that works. This has always
>>> worked for me when I have any screen reader that seems to lose focus.
>>> I don't know if that's what's happening here, but it's just a thought.
>>>
>>> -----Original Message-----
>>> From: Bim Egan [mailto: = EMAIL ADDRESS REMOVED = ]
>>> Sent: Wednesday, October 22, 2014 7:23 AM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Current best practice/standard/guideline for
>>> linking to non-html files?
>>>
>>> Andrew took exception to statements I made in my last email, but my
>>> observations are based only on experience as a screen reader user. I
>>> was wrong in one part, only Word documents opened within Internet
>>> explorer give screen readers difficulty in reproducing a correct reading flow.
>>>
>>> I've rechecked my statements on the difficulties in returning to the
>>> previous page, including using the Escape key, as Andrew suggested,
>>> but it didn't seem to help. The only way I found to get keyboard
>>> focus into the toolbar was to hold down and release the Alt key. This
>>> is counter-intuitive, the normal action is to hold down the Alt key
>>> while pressing the letter key associated with the required menu,
>>> (Alt_F opens the file menu).
>>>
>>> However, once the focus was in the toolbar, I couldn't get it out
>>> again to return to reading the document. The normal action, pressing
>>> the Escape key, didn't work.
>>>
>>> The best experience for screen reader and keyboard only users is to
>>> read alternative formats in their native applications. This underpins
>>> my personal view that identifying changes of format within link text
>>> is as important as notifying the user when a new window will open.
>>>
>>> Bim
>>>
>>>
>>>
>>> On 21/10/2014 15:08, Andrew Kirkpatrick wrote:
>>>> Bim wrote the following, but there are a few inaccurate statements:
>>>>
>>>> As Birkir said, disabled people may need to save files rather than
>>>> have them open up within a browser "shell". For screen reader users
>>>> the reason is that there's little accessibility support in the Adobe
>>>> Reader and MS Office "shells" produced by Internet Explorer. The
>>>> reading flow is often broken, it's not possible to get a list of links or headings, etc.
>>>> These "shells" also make it nearly impossible for keyboard only
>>>> users (including screen reader users), to use keyboard navigation to
>>>> either return to the previous page or navigate between open browser tabs.
>>>> The toolbar is also changed, it's neither the same as the native
>>>> application, nor the originating browser toolbar.
>>>>
>>>> For Adobe Reader in IE the reading flow matches what you get in
>>>> Reader on its own. Of course, if the PDF is incorrectly tagged then
>>>> the reader order may be incorrect, but that is an authoring issue
>>>> rather than a technology issue.
>>>> Lists and headers read correctly when viewing a PDF in IE with Reader.
>>>> I can move from the PDF document to another tab from the keyboard,
>>>> but usually need to hit escape to extract the focus from the object
>>>> within the PDF that it is currently on first.
>>>> Reader doesn't change the toolbar in IE, but does add a toolbar
>>>> specific to Reader, and this is independently keyboard navigable.
>>>>
>>>> In short, I take exception to the statement that there is little
>>>> accessibility support in the Reader plug in for IE.
>>>>
>>>> AWK
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 21/10/2014 13:44, Birkir R. Gunnarsson wrote:
>>>>> Benefits of indicating file types, )ellaborating on what´s already
>>>>> been stated).
>>>>> Users, particularly users with disabilities, may need to open files
>>>>> in "unusual" applications for maximum accessibility (say, they
>>>>> would always want to use AdobeReader rather than opening a PDF
>>>>> document in the browser). By indicating the filetype on the link
>>>>> you give them an opportunity to take the appropriate action, such
>>>>> as right click and save the file rather than opening it.
>>>>> Yes, users can configure their own workstations or mobile devices
>>>>> to always open a certain filetype in a certain application, but
>>>>> users may not always be using their own workstations or devices
>>>>> when browsing the internet.
>>>>> For people with disabilities this is a very important usability issue.
>>>>>
>>>>>
>>>>> Not indicating that a link points to a filetype cannot be called
>>>>> under a WCAG violation, as far as I can see, (and I have tried)
>>>>> unless this information is not available visually.
>>>>> If this info is available visually (e.g. by including an icon as a
>>>>> CSS .background image), it would, however, be a violation of WCAG
>>>>> SC
>>>>> 1.1.1 not to provide that info in some other way.
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> On 10/21/14, Mallory van Achterberg < = EMAIL ADDRESS REMOVED = > wrote:
>>>>>> On Tue, Oct 21, 2014 at 12:14:02AM +0000, Jonathan Avila wrote:
>>>>>>> Benefits for indicating the type apply to people with motor,
>>>>>>> cognitive, and visual impairments. Traversing a link that is not
>>>>>>> the intended link can have more serious consequences for people
>>>>>>> with disabilities because they have to return to where they were.
>>>>>>> An argument can also be made from mobile where large documents
>>>>>>> can take a long time to download or cause the user to incur fees
>>>>>>> for data usage.
>>>>>>>
>>>>>>> Jonathan
>>>>>> Benefits for users who need to keep their rates in mind (mobile
>>>>>> users) and those who know whether or not they even have an
>>>>>> application available that can open it. For example, if I knew I
>>>>>> wanted to avoid .pdf files because I have a crap phone, I now have
>>>>>> the knowledge to stay away.
>>>>>>
>>>>>> I consider it a usability issue.
>>>>>> _mallory
>>>>>> >>>>>> >>>>>> list messages to = EMAIL ADDRESS REMOVED =
>>>>>>
>>>> >>>> >>>> list messages to = EMAIL ADDRESS REMOVED =
>>>> >>>> >>>> list messages to = EMAIL ADDRESS REMOVED =
>>>>
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>>
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
>
> --
> Work hard. Have fun. Make history.
> > > > > >