WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Current best practice/standard/guideline for linking to non-html files?

for

From: Angela French
Date: Oct 22, 2014 11:42AM


Thank you for all the great responses so far!

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL 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 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 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 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 REMOVED>
>>>>>
>>> >>> >>> list messages to <EMAIL REMOVED>
>>> >>> >>> list messages to <EMAIL REMOVED>
>>>
>> >> >> list messages to <EMAIL REMOVED>
>> >> >> list messages to <EMAIL REMOVED>
>>
>
> > > list messages to <EMAIL REMOVED>
>


--
Work hard. Have fun. Make history.