Dynamic Forms, Accessibility, Usability (long)

[Karl Groves]

I am currently working on a Project Journaling Tool which uses a relational
database structure. Naturally the information in the different tables are
used to populate forms for the project journal and the journal's admin
screens.

For instance, to add a note to the journal:

1) User selects the "client" about whom they're making the entry


2) Upon selecting the "Client", we want to narrow down the "Project" list to
only include projects for that client.

3) Upon selecting the "Project", we want to narrow down the "Activity" list
to only include activities for that project.

4) THEN, we can populate the "Budgeted Hours" and "Remaining Hours" fields.

5) Then they add comments, submit the form, etc.




So, my challenge is in creating the dropdowns in the form so that they work
as I've described above, yet keep the whole thing accessible. I could do
this in 5 minutes with JavaScript, or simply refresh the page with
"onChange" to populate those fields.



Either approach is an accessibility issue. Since the site is for a
government agency, we're required by law to adhere to Section 508
guidelines.



Normally, my preferred idea would be to refresh the page with an "onChange"
event handler as the user progresses through the form. I view this as a
lesser-of-two-evils approach to handling the winnowing of options in those
other elements as opposed to actually (re)writing the dropdowns to the page
using javascript. However, this still does not address the "usability for
persons with disabilities" concern of the potential for a complete lack of
support for client-side scripting.



With my approach of using "onChange" to refresh the page, there's the issue
of the form being *completely* unusable for someone whose user-agent doesn't
support scripting. At best, users of screenreaders would be subjected to
listening to the whole page being re-read to them until they were back to
where when the page refreshed. I could set focus on reload to the next
field, which could minimize this problem, but all-in-all I don't see any way
past this issue without some sort of accessibility problem.



The Section 508 guidelines do not specifically mention anything about
refreshing pages, except for "When a timed response is required, the user
shall be alerted and given sufficient time to indicate more time is
required." I don't really view this as applicable, because they'd have all
the time in the world to interact with the form(s). The issue purely
revolves around the fact that the page would be refreshing and that, IMO, is
no different than following a link somewhere. The "usability for persons
with disabilities" issue there is the unexpected change.



Any ideas?



-Karl

 

[GreyWyvern]

[snip - form fret fandango]

Any ideas?

What percentage of your target audience has javascript disabled? What
percentage use text-to-speech? In many cases there *is* such a thing as
"acceptable losses".

Grey

 

[Luigi Donatello Asero]

[snip - form fret fandango]

Any ideas?

What percentage of your target audience has javascript disabled? What
percentage use text-to-speech? In many cases there *is* such a thing as
"acceptable losses".

Grey

--

If you do not have javascript disabled you might get virus don´t you?
http://www.corriere.it/Primo_Piano/Scienze_e_Tecnologie/2004/06_Giugno/25/virus.shtml

 

[Karl Groves]

[snip - form fret fandango]

Any ideas?

What percentage of your target audience has javascript disabled? What
percentage use text-to-speech? In many cases there *is* such a thing as
"acceptable losses".

I agree completely with you on "acceptable losses".
The truth is (AFAIK), fully 0.0% of users access the site with scripting
disabled and/ or text-only/ text-to-speech user agents.
My issue is in complying with Fed Rehab Act Section 508.

-Karl

 

[Luigi Donatello Asero]

wrote:

[snip - form fret fandango]

Any ideas?

What percentage of your target audience has javascript disabled? What
percentage use text-to-speech? In many cases there *is* such a thing as
"acceptable losses".

I agree completely with you on "acceptable losses".
The truth is (AFAIK), fully 0.0% of users access the site with scripting
disabled and/ or text-only/ text-to-speech user agents.

I usually have javascript disabled. It sounds strange to me that no other
user has javascript disabled.

 

[Bill Logan]

I am currently working on a Project Journaling Tool which uses a relational
database structure. Naturally the information in the different tables are
used to populate forms for the project journal and the journal's admin
screens.

For instance, to add a note to the journal:

1) User selects the "client" about whom they're making the entry


2) Upon selecting the "Client", we want to narrow down the "Project" list to
only include projects for that client.

3) Upon selecting the "Project", we want to narrow down the "Activity" list
to only include activities for that project.

4) THEN, we can populate the "Budgeted Hours" and "Remaining Hours" fields.

5) Then they add comments, submit the form, etc.

If you are refreashing the page anyway - why use JS? PhP would do the job ok
without the accessability issues. And if you are on a windos box I am sure thee
is a similar option (asp?) This way the result is all html - no access issue.

 

[Whitecrest]

I agree completely with you on "acceptable losses".
The truth is (AFAIK), fully 0.0% of users access the site with scripting
disabled and/ or text-only/ text-to-speech user agents.
My issue is in complying with Fed Rehab Act Section 508.

Actually 508 allows for this.

But why not populate the dropdowns with everything, then if someone does
not have javascript turned on, or is using a reader they get the entire
list. then change everything with javascript to narrow the list.

This way if you have JS turned off, you have a big list and see
everything, and if you have it turned on (like the majority of your
clients) then you see a narrowed list like you like.

 

[Manas Tungare]

I could do this in 5 minutes with JavaScript, or simply refresh
the page with "onChange" to populate those fields.

How about providing two ways to refresh the page? (1) Your JavaScript
code, and (2) a button next to the dropdown.

Furthermore, you could have code in your script to hide that button. So,
if the user agent supports scripting, the page will refresh
automatically for them with no ungainly buttons. If the user agent does
not support scripting, they can use the button (which will of course
stay visible).

This will ensure two purposes: (1) You don't tax the majority of users
for catering to the minority, and (2) more importantly, you don't ignore
the minority either.

 

[Bradley K. Sherman]

Everyone using IE on Intel should have javascript turned OFF
as there is yet another major security hole in the Microsoft
bloated pig of a browser and in its inferior IIS HTTPD.

<http://news.google.com/news?hl=en&edition=us&ie=ascii&q=javascript+virus>

--bks

 

[rf]

Everyone using IE on Intel should have javascript turned OFF
as there is yet another major security hole in the Microsoft
bloated pig of a browser and in its inferior IIS HTTPD.

Yawn...

 

[Alice]

Hi,

I am no expert with database, but you may want to consider using XML,
which then creates the HMTL page really easily. Here is a single
reference, but I am sure there are plenty on the web:

http://otn.oracle.com/oramag/oracle/03-may/o33xml.html

That way everytime you refresh you get the data you want. And you
dont have to worry about javascript.

Also one of the main issues with people with visual impairement is
that in drop-down menus, or boxes the font doesn't change if you
change the font size through internet explorer. If you use html and do
not use css to determine your font size, then people can change the
font size using the their webbrowser. So I do suggest having the text
displayed in the screen using HTML.

PHP is also a very good option, as it works well with databases.

Good luck!

Alice

 

[Chris Morris]

I am currently working on a Project Journaling Tool which uses a relational
database structure. Naturally the information in the different tables are
used to populate forms for the project journal and the journal's admin
screens.

For instance, to add a note to the journal:

1) User selects the "client" about whom they're making the entry


2) Upon selecting the "Client", we want to narrow down the "Project" list to
only include projects for that client.

3) Upon selecting the "Project", we want to narrow down the "Activity" list
to only include activities for that project.

4) THEN, we can populate the "Budgeted Hours" and "Remaining Hours" fields.

5) Then they add comments, submit the form, etc.

Hmm. Ignore 4 - you can populate those server-side on form
submission. Unless you need to display them, I suppose, but you could
put that in the activity list.
<option value="cl7_pr24_ac11">Testing Phase (3 budgeted, 2 remaining)</option>

You can use <optgroup> to merge either Client-Project or
Project-Activity into a single <select>.

So - one possibility:

form page (meta code, some client-side JS, mostly server-side, should
be obvious which is which to get it to work reliably)

if (!set(stage)) {
display form part 1 (optgrouped client/project combinations)
if (js && js has necessary capabilities) {
on select in part 1 {
display form part 2 (restricted on part 1)
hidden input (stage = 2)
display submit button
}
} else {
hidden input (stage = 1)
display submit button
}
} elsif (stage = 1) {
read input from part 1
display form part 2 (restricted on part 1)
hidden input (stage = 2)
display submit button
} elsif (stage = 2) {
process form data
}