E-mail List Archives

Search E-mail List Archives for

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

From: james.kalbach
Date: Thu, Dec 22 2005 2:20AM
Subject: Inactive Buttons - ALT Tags?
No previous message | Next message →

Hi,



I have a situation where a button is inactive until something is selected on
the page. Visually, it has two different colors (in an inactive state, the
button is grey; when active, it's beige). What's the best way to handle ALT
tags for the two different states?



1.

Inactive: ALT = ""

Active: ALT = "Submit"



2.

Inactive: ALT = "unavailable" (or 2b: "unavailable - please make selections
first"?)

Active: ALT = "Submit"



3

Inactive: ALT = "Submit, inactive"

Active: ALT = "Submit, active"



Or another possibility? Anyone ever come across this situation or know of
any examples?



Thanks

James



:: James Kalbach : Human Factors Engineer : User Experience : LexisNexis
::
:: Home Office - Bellealliancestr. 34, D-20259 Hamburg, Germany ::
:: T.+49 40 4149 5338 ::



This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed

From: Jukka K. Korpela
Date: Thu, Dec 22 2005 3:00AM
Subject: Re: Inactive Buttons - ALT Tags?
← Previous message | Next message →

On Thu, 22 Dec 2005, = EMAIL ADDRESS REMOVED = wrote:

> I have a situation where a button is inactive until something is selected on
> the page.

Then the main question is: how does the page work when scripting is
disabled?

Inactive buttons should only appear as generated by client-side scripting,
so that they will not be present at all when scripting is off, i.e. when
there is no way to make them active. Consequently, you could and normally
should delay the generation of such buttons so there are no inactive
buttons.

> Visually, it has two different colors (in an inactive state, the
> button is grey; when active, it's beige).

Is the user expected to understand such symbolic use of colors?
Even when he is colorblind, or blind?

> What's the best way to handle ALT
> tags for the two different states?

What "ALT tags"? There are no such tags. And ALT _attributes_ are to be
used in some elements only, and you have given no hint of using such
elements. If you gave the URL, we could perhaps see what you really mean.
Do you mean "button-like image" when you write "button"? That's a yet
another problem, and not just a matter of using ALT attributes.
To begin with, text in an image cannot be enlargened or changed to a more
readable font. (Some browsers allow zooming in general, but IE doesn't.)

> Or another possibility?

Try starting from the original problem, not the problems you have created
in an attempt to deal with some unspecified situation.

If this is about a submit button, then it should be a normal submit
button, period. Stop using an image submit button, and many problems
vanish in a puff of logic.

If you want to make a submit button disabled until some fields have been
filled, the only accessible and reasonable approach is to generate it in
JavaScript, naturally with
<noscript><input type="submit" ...></noscript>
In the JavaScript-generated content, you could have a text saying that you
need to fill out the required fields before you are able to submit the
form data, then replace this by submit button.

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

From: Andrew Kirkpatrick
Date: Thu, Dec 22 2005 8:20AM
Subject: RE: Inactive Buttons - ALT Tags?
← Previous message | Next message →

> To begin with, text in an image cannot be enlargened or
> changed to a more readable font. (Some browsers allow zooming
> in general, but IE doesn't.)

You can do this in IE if you set the height/width in ems, but you will
get a loss of image quality unless you are using a scalable image type.

> If you want to make a submit button disabled until some
> fields have been filled, the only accessible and reasonable
> approach is to generate it in JavaScript, naturally with
> <noscript><input type="submit" ...></noscript> In the

I'd recommend using a submit button also, but not to use noscript.
Noscript content is not read by JAWS, whether scripting is enabled or
not, so it would be better to use the standard submit button and use
javascript to modify the disabled attribute to be disabled="disabled".
Then, if scripting is off, the button will work (and your data
validation will need to take place server-side).

AWK

Andrew Kirkpatrick
Accessibility Engineer
Adobe Systems
= EMAIL ADDRESS REMOVED =

From: Jared Smith
Date: Thu, Dec 22 2005 9:00AM
Subject: Re: Inactive Buttons - ALT Tags?
← Previous message | Next message →

Jukka has brought up most of the problems. Let me perhaps present them in
a less critical fassion.

> I have a situation where a button is inactive until something is
> selected on the page.

Using JavaScript, I suppose. If JavaScript is disabled or unavailable, you
should ensure that the page still functions properly.

> Visually, it has two different colors (in an
> inactive state, the button is grey; when active, its beige).

Fantasic. The use of color can be very helpful for visual users. However,
the use of color alone may not be enough to convey the state of the
button, especially if the user cannot see color.

Some screenreaders will not read form elements that are truly set to be
disabled (disabled="disabled").

> Whats the best way to handle ALT tags for the two different states?

The ALT attribute (and there's no law against calling them TAGS!) would
not apply to button form elements. You should instead be setting the VALUE
attribute. If you are using <input type="image">, then you must use ALT
text. You should also be aware that low vision users may have difficulties
reading the image button if it is enlarged.

There are several JavaScript methods that could be used to do what you are
presenting (again, understanding that JavaScript must be enabled). You
could use JavaScript to hide/unhide the buttons based on the state of the
other page element. You could also use JavaScript and DOM to change the
ALT (or VALUE) attributes. The problem with this approach is that you
cannot necessarily be certain that the user will access the form elements
in the order you prescribe.

As Andrew pointed out, using NOSCRIPT would seem like a very logical way
of providing functionality when JavaScript is disabled, but JAWS never
reads it (WHY???).

The best approach would be to do the logic using server-side scripting. If
it is something like, "you must check the box to accept our terms of use
before submitting the form" type thing, then simply allow the form to
function and be submitted normally, then provide the feedback after the
form is submitted.

Of your ALT options, I'd probably go with 2b. Because the button performs
some function, alt="" would not be appropriate (it never is for images or
image buttons that are clickable). I'd provide the necessary feedback to
the user when the button is accessed.

Jared Smith
WebAIM.org

From: Jared Smith
Date: Thu, Dec 22 2005 10:20AM
Subject: Re: Inactive Buttons - ALT Tags?
← Previous message | Next message →

Andrew Kirkpatrick wrote:
>>Some screen readers will not read form elements that are truly
>>set to be disabled (disabled="disabled").
>
>
> Jared - do you have specifics?

The problem (at least in JAWS) is that disabled form elements are not read
when navigating through the form. They are not 'navigable'. They are read
if you simply let the screen reader read though the contents of the page,
but are skipped when tabbing through the links/form elements of the page,
which is how most forms are going to be completed.

Visually one could see that the form element is there, but disabled. A
screen reader user likely will not even know it exists.

Jared

From: Andrew Kirkpatrick
Date: Thu, Dec 22 2005 11:00AM
Subject: RE: Inactive Buttons - ALT Tags?
← Previous message | Next message →

> Some screenreaders will not read form elements that are truly
> set to be disabled (disabled="disabled").

Jared - do you have specifics? I tried this with JAWS 4.50-7.0,
Window-Eyes 5.5, and HPR 3.04 and it works well. I don't have older
versions of W-E readily available and I haven't tried it on VoiceOver,
EmacSpeak, Gnompernicus, or any other SR - any additional info is
appreciated.
AWK

From: Carol E. Wheeler
Date: Thu, Dec 22 2005 11:40AM
Subject: RE: Inactive Buttons - ALT Tags?
← Previous message | Next message →

As far as buttons go, you can either do a pure CSS button, or a hybrid
(button back ground image, with CSS list over), either of which works
without an image at all, and can be styled anyway you want for sighted
users.

Carol E. Wheeler
American Library Association
Washington Office
202.628.8410 v
202.403.8495 f

From: james.kalbach
Date: Fri, Dec 23 2005 3:40AM
Subject: RE: Inactive Buttons - ALT Tags?
← Previous message | Next message →

Thank you for your constructive, helpful answer, Jared.

[Jared Wrote]
> Of your ALT options, I'd probably go with 2b. Because the button
> performs some function, alt="" would not be appropriate (it never is
> for images or image buttons that are clickable). I'd provide the
> necessary feedback to the user when the button is accessed.

In its inactive state, the image button is not clickable. Would you still
recommend ALT="Unavailable - please make selections first"?

Cheers,
Jim

From: Andrew Kirkpatrick
Date: Fri, Dec 23 2005 9:40AM
Subject: RE: Inactive Buttons - ALT Tags?
← Previous message | No next message

> The problem (at least in JAWS) is that disabled form elements
> are not read when navigating through the form. They are not
> 'navigable'. They are read if you simply let the screen
> reader read though the contents of the page, but are skipped
> when tabbing through the links/form elements of the page,
> which is how most forms are going to be completed.
>
> Visually one could see that the form element is there, but
> disabled. A screen reader user likely will not even know it exists.

I can agree that in this case it would be desireable for the button to
be tabbable and announced when in forms mode, but not in all cases would
you want disabled controls to be voiced.

Imagine a pair of radio buttons for a search engine - one reads "no
language preference" and the other reads "I have preferred languages".
If the second is selected then there is a list of many languages that
are labels for checkboxes for the user to indicate choices. If the user
doesn't want to set a language, should they have to tab through
everycheckbox? They can hear them out of forms mode, but it is
convenient to skip them for both the keyboard and screen reader user.

Better control of whether a disabled item is in the tab order
(particularly for SR users) would be useful here.

In this case, the button appears enabled when information is typed into
the form. If the user enters forms mode they are likely to enter
information into the form, so they would encounter a fully enabled
button. The only time that there would be an issue is when they want to
revew every field in the form before typing anything - but would users
notice that the submit button is missing? I doubt it.

I'd vote for the button in this situation, but wouldn't balk too much at
the solution you propose either.

AWK