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 21, 2014 7:43AM

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