WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Andrew Kirkpatrick
Date: Oct 21, 2014 8:08AM

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>
>>
>