WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Bim Egan
Date: Oct 22, 2014 7:22AM


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