E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Ruth Stillman
Date: Sun, Jan 05 2003 12:16PM
Subject: Use of title attribute in links
No previous message | Next message →

I am in the process of retro-fitting an application for a client so that
it meets P1 and P2 accessibility. One of the biggest issues I have found
is that the application uses a lot of javascript pop-ups for help text,
glossary, etc. Is it possible to use the title attribute to alert users
to the fact that the link will open in a new window? Is the title supported
by screen readers?

Thanks,
Ruth Stillman


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Jukka K. Korpela
Date: Sun, Jan 05 2003 12:52PM
Subject: Re: Use of title attribute in links
← Previous message | Next message →

On Sun, 5 Jan 2003, Ruth Stillman wrote:

> I am in the process of retro-fitting an application for a client so that
> it meets P1 and P2 accessibility. One of the biggest issues I have found
> is that the application uses a lot of javascript pop-ups for help text,
> glossary, etc.

The best approach is to replace them by normal links. But if such
accessibility is unacceptable, for some reason, then you could turn the
JavaScript surrogates for links to real links with optional JavaScript
handlers. Schematically, instead of
<a href="javascript:foo()">
you would have
<a href="useful.html" onclick="foo();return false">

This would address the issue of being useable at all when client side
scripting is not supported, or has been disabled.

The popup would still be a problem. See the note about the best approach
above.

Technically, Guideline 10.1 is ambiguous (rather paradoxically):
"Until user agents allow users to turn off spawned windows, do not cause
pop-ups or other windows to appear and do not change the current window
without informing the user."
Does "without informing the user" apply to all the preceding rules, or
just the last one (about changing current window)?

> Is it possible to use the title attribute to alert users
> to the fact that the link will open in a new window?

In a sense it is, but
a) that's not what title means, really - it should be an advisory
title for an element or a resource, not a warning about some
events; and, more seriously,
b) there is no requirement that the title attribute value be presented
to the user, or even used in any wat; and not all browsers support
it at all, and those that do, do it rather poorly - in particular,
they show the text for a short time only, creating one of the
problems we're trying to avoid.

If you read Guideline 10.1, questionably, as prohibiting popups only if
the user is not informed, then the reasonable approach is to include the
information into the page as its normal content. Such as
<noscript>
On JavaScript-enabled browsers, links on this page will open in a new
window.
</noscript>
at the _beginning_ of the page (before the first link).


--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Holly Marie
Date: Mon, Jan 06 2003 10:49AM
Subject: Re: Use of title attribute in links
← Previous message | Next message →

----- Original Message -----
From: "Jukka K. Korpela" < = EMAIL ADDRESS REMOVED = >

> On Sun, 5 Jan 2003, Ruth Stillman wrote:
>
> > I am in the process of retro-fitting an application for a client so that
> > it meets P1 and P2 accessibility. One of the biggest issues I have
found
> > is that the application uses a lot of javascript pop-ups for help text,
> > glossary, etc.
>
> The best approach is to replace them by normal links. But if such
> accessibility is unacceptable, for some reason, then you could turn the
> JavaScript surrogates for links to real links with optional JavaScript
> handlers. Schematically, instead of
> <a href="javascript:foo()">
> you would have
> <a href="useful.html" onclick="foo();return false">
>
> This would address the issue of being useable at all when client side
> scripting is not supported, or has been disabled.
>
> The popup would still be a problem. See the note about the best approach
> above.

Not meaning to further rain on any parade here... when using javascript to
pop up such pieces, it is also very important to include the device
independent event handlers[associated mouseless actions] ...
.onClick(onclick), for instance does not work for someone using a keyboard,
tabbing, pointing, or other device.... so this issue also needs to be
addressed.

=== How To make more accessible Event Handlers ==
Quoted information below is From:
12.4 Directly accessible scripts
<http://www.w3.org/TR/WCAG10-HTML-TECHS/#directly-accessible-scripts>;

An event handler is a script that is invoked when a certain event occurs
(e.g, the mouse moves, a key is pressed, the document is loaded, etc.). In
HTML 4.01, event handlers are attached to elements via ** event handler
attributes (the attributes beginning with "on", as in "onkeyup").
Some event handlers, when invoked, produce purely decorative effects such as
highlighting an image or changing the color of an element's text. Other
event handlers produce much more substantial effects, such as carrying out a
calculation, providing important information to the user, or submitting a
form. For event handlers that do more than just change the presentation of
an element, content developers should do the following:

(** Event handler attributes:
onblur, onchange, onclick, ondblclick, onfocus, onkeydown, onkeypress,
onkeyup, onload, onload, onmousedown, onmousemove, onmouseout, onmouseover,
onmouseup, onreset, onselect, onsubmit, onunload )

1. Use application-level event triggers rather than user interaction-level
triggers. In HTML 4.01, application-level event attributes are "onfocus",
"onblur" (the opposite of "onfocus"), and "onselect". Note that these
attributes are designed to be device-independent, but are implemented as
keyboard specific events in current browsers.

2. Otherwise, if you must use device-dependent attributes, provide redundant
input mechanisms (i.e., specify two handlers for the same element):

[*] Use "onmousedown" with "onkeydown".
[*] Use "onmouseup" with "onkeyup"
[*] Use "onclick" with "onkeypress"
Note that there is no keyboard equivalent to double-clicking
("ondblclick") in HTML 4.01.

3. Do not write event handlers that rely on mouse coordinates since this
prevents device-independent input.

[end quoted]

Also see: 12 Scripts
<http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts>;
for more scripting information and accessibility.


holly


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Kynn Bartlett
Date: Mon, Jan 06 2003 2:31PM
Subject: Re: Use of title attribute in links
← Previous message | Next message →

It's possible to do this, but it's better to tell ALL users that the
link will
open in a new window. I suggest using these types of "best practices"
which
surpass minimal accessibility requirements, instead of attempting to
meet the
"spirit of the law" for specific checkpoints.

--Kynn

On Sunday, January 5, 2003, at 11:02 AM, Ruth Stillman wrote:

> I am in the process of retro-fitting an application for a client so
> that
> it meets P1 and P2 accessibility. One of the biggest issues I have
> found
> is that the application uses a lot of javascript pop-ups for help text,
> glossary, etc. Is it possible to use the title attribute to alert
> users
> to the fact that the link will open in a new window? Is the title
> supported
> by screen readers?
--
Kynn Bartlett < = EMAIL ADDRESS REMOVED = > http://kynn.com
Chief Technologist, Idyll Mountain http://idyllmtn.com
Author, CSS in 24 Hours http://cssin24hours.com


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Susan
Date: Mon, Jan 06 2003 3:51PM
Subject: link to word documents
← Previous message | Next message →

I have been asked to check a web site for to see if it complies with an
organisation's equal opportunity policy. Well what they really mean is
for accessibility.

They have a list of links to get further information about their
products but when the links are followed all this information is in word
documents. Apart from the obvious possibility of incompatibility with
other word processors or even other versions of word are there any
accessibility issues with this arrangement.

I suspect there might be a problem if styles were not used with word but
I am not sure. Another suspicion I have is that some equipment might not
easily change from reading text in a browser to reading text in a word
document.

Susan

www.preparedhome.co.uk
www.poundsmeetends.co.uk





----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Paul Bohman
Date: Mon, Jan 06 2003 4:51PM
Subject: RE: link to word documents
← Previous message | Next message →

For most kinds of disabilities, Word documents are not much of a problem in
terms of accessibility. There are no special challenges for someone who is
deaf, for example. Someone who is unable to use a mouse will still be able
to navigate quite effectively through the Word interface (there are plenty
of keyboard shortcuts). Someone using a screen reader usually can handle
basic Word documents without too much trouble as well. Screen readers such
as JAWS and Window Eyes are good at reading the Word interface and
documents.

However, not everyone uses a full screen reader. If the user has a program
that reads only Web documents and email, such as Home Page Reader or Connect
Outloud, then the Word documents will be inaccessible. This is not a common
scenario, but it is one to be aware of.

Also, it is possible to create Word files that are very confusing. Complex
tables with merged columns and rows can be nearly indecipherable. The
simpler the document, the better.

Another useful technique within Word is to use heading levels properly. Most
people simply enlarge the font size and use a bold font style to denote
headings within a document. When headings are used properly it is possible
to navigate the document within a screen reader by headings. This makes the
document more usable.

As far as styles are concerned, the only one that makes a real difference is
the heading styles. If you use true headings (from the styles menu) you'll
be better off. The other styles are not important from an accessibility
standpoint.

Images within Word documents will be inaccessible if there is no alternative
text for them. You can create alternative text by right-clicking on the
picture, going to Format Picture > Web > Alternative text. You can also
provide a caption right in the text of the document itself so that everyone
can see it (this is the best method, as long as the caption adequately
describes the image's purpose to someone who can't see it).

One thing to consider is that some people have their browser configured to
open Word files directly, within the browser, and not within the Word
interface. This may be convenient for some of us, but it reduces the
usability of Word files for someone who depends on keyboard navigation
within Word. Since this is a user setting, you can't control whether or not
the Word document opens in the browser (unless perhaps if you put the Word
file on an FTP server instead of an HTTP server--you would have to test
this). It's true that users needs to bear some responsibility for their own
preferences and settings, but some are simply not savvy enough to be able to
change them.

In terms of switching between a Web browser and word processor program, I
wouldn't be too concerned about this. Full screen readers do an acceptable
job at switching back and forth.

One of the biggest drawbacks is the disorientation that occurs when you
click on a link and another program opens up. People assume that most links
will lead to another Web page. When they see Word start to open, many people
will go back in their browser or immediately shut down Word, to avoid having
another program open.

The ideal solution would be to have the documents available in HTML format.
If necessary, you could provide them in both formats, giving the user a
choice. If you convert the files to HTML, make sure that the resulting files
are accessible! Word XP comes with an option to save files to "filtered
HTML", which is Microsoft's way of saying "HTML without all the unnecessary
nonsense that we normally bloat the document with."

In the specific case that you mentioned, it doesn't make sense that a
company or any organization would want to provide information about their
products in Word format alone. It would seem to me that this is "mission
critical" information. They can't risk losing a sale just because they're
unmotivated to convert their Word documents into HTML. If someone can't
access the Word file--for whatever reason--they're unlikely to buy the
product.

Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Center for Persons with Disabilities
www.cpd.usu.edu
Utah State University
www.usu.edu

From: Kynn Bartlett
Date: Mon, Jan 06 2003 6:47PM
Subject: Re: link to word documents
← Previous message | Next message →

On Monday, January 6, 2003, at 02:27 PM, Susan wrote:
> They have a list of links to get further information about their
> products but when the links are followed all this information is in
> word
> documents. Apart from the obvious possibility of incompatibility with
> other word processors or even other versions of word are there any
> accessibility issues with this arrangement.

I agree with what Paul Bohman had to say in another reply. I will add
that I believe
it is more useful to provide documents in HTML and PDF instead of
providing them in
HTML and Word. If you are providing a document in a "formatted"
version, such as
Word or PDF, it is better practice to use PDF.

The advantages of PDF are:

* If made correctly, they support structural encoding readable by newer
versions of
the Adobe reader.

* The Acrobat PDF reader is available for free on nearly every platform.

* PDF is often a read-only format (although not exclusively so) and is
thus better
for distribution than Word, which is designed to be editable easily.

* Word files can often contain unintentional information which you
don't wish to
reveal, because Word stores additional information with each file.
For example,
deleted text or information about your computer system is often
stored in a
Word file, and you may not want to release that information.

* Word files can be used to spread destructive macro viruses, while
that danger
does not exist in PDF.

This is _not_ to say that you should use PDF exclusively; you should
offer an HTML
version as well. However, if you have a choice as to which formats to
use, I prefer
them in this order:

1. HTML
2. PDF
3. Word

Also, if you are providing files which _are_ meant to be edited, then
clearly
Word (or RTF) is better in such a case.

--Kynn

--
Kynn Bartlett < = EMAIL ADDRESS REMOVED = > http://kynn.com
Chief Technologist, Idyll Mountain http://idyllmtn.com
Author, CSS in 24 Hours http://cssin24hours.com


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Holly Marie
Date: Tue, Jan 07 2003 6:00AM
Subject: Re: link to word documents
← Previous message | Next message →

From: "Kynn Bartlett"


>
> On Monday, January 6, 2003, at 02:27 PM, Susan wrote:
> > They have a list of links to get further information about their
> > products but when the links are followed all this information is in
> > word
> > documents. Apart from the obvious possibility of incompatibility with
> > other word processors or even other versions of word are there any
> > accessibility issues with this arrangement.
>
> I agree with what Paul Bohman had to say in another reply. I will add
> that I believe
> it is more useful to provide documents in HTML and PDF instead of
> providing them in
> HTML and Word. If you are providing a document in a "formatted"
> version, such as
> Word or PDF, it is better practice to use PDF.

I disagree about PDF being a better pratice, though I do believe offering
the HTML alternative is preferred in all choices.
PDF also take longer to download. The larger or more complex this file is,
the longer it will take to download. On the other hand multipaged HTML
downloads just that page at a time, not the whole chunk. Therefor if a user
is online looking for a single topic in a User Manual or other such
document, if it is in that PDF document, they may have to download the Whole
200+ pages or more[sometimes less], in order to retrieve that information.
This is not acceptable in ease of access. [I may go out on a limb, but I
highly doubt these online PDF manuals have been converted over in accessible
ways.]

For the average user, PDF is not User Friendly, full page readability means
less content is seen and more manipulation of the pages and between pages is
needed. IT is highly difficult for even average users to read a PDF document
online. Requiring a user to print these documents for reading is rather bad
design for the user, and not the most accessible solution for the low or
non visual users.

And how good are these conversions overall? Are they acceptable and easier
to follow or use as an HTML page.

Personally, if PDF is offered on any site I might put together: HTML and
Text will probably be the added choices and then the only reason to really
offer the PDF is for a better printable solution. Other accessibility issues
can be better met with HTML and even text files.

> The advantages of PDF are:
>
> * If made correctly, they support structural encoding readable by newer
> versions of
> the Adobe reader.

I wonder what percentage of PDF's out there are made correctly? How many
people are aware of how to make these correctly? And I wonder about the ease
in making these documents more accessible?
If someone does not have Acrobat Reader they will need to download and
install one. This process will require a visit to Adobe, forms, and then
download.

PDF is a print document in most cases. Accessibility is then linked to a
user who has technology to Scan these documents[though OCR may not scan
these perfectly well or translate the information well when converted]

> * The Acrobat PDF reader is available for free on nearly every platform.

Web browsers are the same. Free for every platform on the web.
Flash may be more accessible to those with cognitive and motor challenges,
where PDF falls short. Manipulating and scrolling pages in PDF format can be
a challenge. Quite often PDFs I encounter are at less than 100% of the
printable text to fit to web pages and need to be enlarged for average
optimal readability. IF a person needs to enlarge these even more for visual
perception challenges, these documents become an added challenge to
manipulate between lines, paragraphs, pages, and keeping a smooth reading
flow is difficult.

The PDF GUI is not as intuitive as a web page might be. A simple search and
find command for words or text from the keyboard is not quite as easy.

The lack of smoother scrolling in a PDF is an accessibility challenge for
those with motor differences, and those not familiar with the PDF interface.

> * PDF is often a read-only format (although not exclusively so) and is
> thus better for distribution than Word, which is designed to be editable
easily.

I am trying to understand where this makes it better for the end user?
I would think that easy edit follows better guidelines for Accessibility and
Tools or Editing Applications. Just how easy is it for someone to edit or
make a PDF document accessible? Are these cues and instructions easy to find
and understand? Is the authoring or editing software easy to use when making
accessible read only documents?


> * Word files can often contain unintentional information which you
> don't wish to reveal, because Word stores additional information with each
file.
> For example, deleted text or information about your computer system is
often
> stored in a Word file, and you may not want to release that information.

This sounds like more of an issue from the standpoint of the author of the
document. How is this an accessibility issue for the end user?
Is this a case where the authoring person needs to know what is in their
Word document going out?

> * Word files can be used to spread destructive macro viruses, while
> that danger does not exist in PDF.

Web browsers, email, Flash, and other media delivery can spread viruses,
though I do agree that macros are possible in word documents. HTML pages can
spread web viruses, too. Pop up advertising, too.


> This is _not_ to say that you should use PDF exclusively; you should
> offer an HTML version as well.

Much better solution.

However, if you have a choice as to which formats to
> use, I prefer
> them in this order:
>
> 1. HTML
> 2. PDF
> 3. Word

PDF was actually meant to be a printed format, not a readable format online.
Its optimal use online is not as high as it could be.
Scrolling pages remains a challenge for those with disabilities and average
users alike.
Care needs to be taken if this document is geared for web as well as print,
and it might be nice if most opened up with text or viewability at 100% for
the starting point.
Care needs to be taken to make sure that these PDF documents are also
accessible.[this can be a challenge, too.]
Optimal navigation is important on lengthy or technical pieces, such as:
manuals, instructions, reports, etc. [inside document linking?]
Are Links included for next and back at the bottoms of each page? [the PDF
page navigation arrows are very diffucult for many]
Is there an index and a quick access to topics and subtopics available?
[again links help here, including links in the context]

Most of the PDFs I see do not seem more accessible and are more difficult to
manipulate than a web page.


Downloadable [Free] courseware for Instructors and Students [available in
5.4mb zip files]
http://www.adobe.com/products/acrobat/access_info.html#training

Creating Accessible PDF documents
http://www.adobe.com/products/acrobat/access_booklet.html


holly




----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Kynn Bartlett
Date: Tue, Jan 07 2003 3:17PM
Subject: Re: link to word documents
← Previous message | No next message

On Tuesday, January 7, 2003, at 04:39 AM, Holly Marie wrote:
> I disagree about PDF being a better pratice, though I do believe
> offering
> the HTML alternative is preferred in all choices.
> PDF also take longer to download. The larger or more complex this file
> is,
> the longer it will take to download. On the other hand multipaged HTML
> downloads just that page at a time, not the whole chunk. Therefor if a
> user
> is online looking for a single topic in a User Manual or other such
> document, if it is in that PDF document, they may have to download the
> Whole
> 200+ pages or more[sometimes less], in order to retrieve that
> information.
> This is not acceptable in ease of access. [I may go out on a limb, but
> I
> highly doubt these online PDF manuals have been converted over in
> accessible
> ways.]
>
I'm confused.

I was arguing that PDF is better than Word.

You are referring to the advantage of HTML over PDF. That has never
been in
dispute.

> Most of the PDFs I see do not seem more accessible and are more
> difficult to
> manipulate than a web page.

I think you have seriously misunderstood my post. My recommendation is
that
instead of providing Word, or providing Word and HTML, one should
instead provide
PDF and HTML.

--Kynn

--
Kynn Bartlett < = EMAIL ADDRESS REMOVED = > http://kynn.com
Chief Technologist, Idyll Mountain http://idyllmtn.com
Author, CSS in 24 Hours http://cssin24hours.com


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/