[Irl-dean] Disabled Form Input fields

[Joshue O Connor]

Hi Eoin,

>> I think you may have misunderstood what i meant by "Lookup" mode.
[...]
>> So in Lookup mode, when you go to look up a record, the form is always
>> displayed, with the fields of the form populated with the information that's
>> been pulled off the database for that record.



No I understand but my idea may not be suitable for what you need. I
meant that when the data is being retrieved from the database the form
can be hidden, an animation displayed and them the form returned with
the results (though I may have not made that final part clear).

Lars idea is fine but if the form elements are marked up well in the
first place then they should suffice, and be perfectly accessible.

I am inclined to think however that you don't need to do anything
really, aside from structure/markup the form well and style it the way
you wish. It sounds fairly straight forward. If the user is entering
content then once finished they don't generally expect to have to enter
anymore, especially if all of the required or necessary fields have been
filled and when they are submitting a query the search parameters are
defined according to their requirements and usually presented in an a
way the author thinks is suitable.

Cheers and I hope that you work it out (which I am sure you will) :-)

Josh



MacIonmhain, Eoin wrote:
> Hi Josh,
> 
> Thanks for that!
> 
> I think you may have misunderstood what i meant by "Lookup" mode. Looking
> back on my first mail, i probably didn't make it that clear. What the
> application does is basically give you a webpage where you can either input
> data for a record into the database, or look it up from the database so that
> you can see what data a particular record on the database contains.
> 
> So in Lookup mode, when you go to look up a record, the form is always
> displayed, with the fields of the form populated with the information that's
> been pulled off the database for that record.
> 
> So we want the user to be able to see (or have a screen reader read to them)
> all the values that are contained in the form fields, as populated from the
> database record - but: we don't want them to be able to edit any of the
> values in the fields.
> 
> Cheers
> 
> Eoin
> 
> 
> 
> -----Original Message-----
> From: irl-dean-admin at list.eeng.dcu.ie
> [mailto:irl-dean-admin at list.eeng.dcu.ie]On Behalf Of Joshue O Connor
> Sent: 11 July 2007 16:48
> To: irl-dean at list.eeng.dcu.ie
> Subject: Re: [Irl-dean] Disabled Form Input fields
> 
> 
> *************************************
> 
> This e-mail has been received by the Revenue Internet e-mail service. (IP)
> 
> *************************************
> 
> Hi Eoin,
> 
>>> It's looking the data up from a database alright (it's an Ingres DB),
> there's
>>> no problem at all with it populating the fields etc from the DB, just with
>>> making the fields non-editable.
> 
> Off the top of my head, one way would be to actually hide the form when
> 'Look up' mode was being activated and display a little Flash animation
> (revolving circles etc) or similar when the application was in this
> mode. Once out of 'lookup' mode the form would be redisplayed, without
> any need for disabling form elements. You could do this with a
> combination of Javascript/Flash or by wrapping the form in a PHP include
> (if using PHP) that is triggered (removed) on certain server calls -
> like calling the 'look up' action/function. The animation itself would
> not have to be made accessible, as such as it is primarily eye candy,
> while the behind the scenes look up is taking place, as it has no
> content to describe - just make sure it can be quietly ignored by the
> screen reader user.
> 
>>> Another related accessibility issue has come up just there - someone's
>>> pointed out that if form fields are set as disabled - JAWS will ignore
> them
>>> as you tab through the form. So even if the contrast issue is solved,
> there's
>>> probably a screen reader issue as well. 
>>>
>>> I think I read somewhere that if JAWS is just reading the full contents of
>>> the page that the disabled fields will be read out, but that tabbing isn't
>>> available for disabled fields, but I'm not sure about this...
> 
> The above approach  would  remove any issues with JAWS and disabled form
> fields, as the form fields are hidden when there is no needed or desired
> user input. This is an issue that I have not come across so I would be
> glad to test it for you if you want to send me links to some samples off
> list.
> 
>> A potential solution might be to set the background of disabled fields to a
>> colour that provides a bit more contrast to the grey, but it's hardly
> ideal,
>> and will most likely look quite bizarre!
>>
>> Does anyone have any thoughts? Is there any way to control a browser's
>> greying of the contents of disabled fields?
> 
> You should also be able use CSS to style the form elements in any way -
> regardless of mode. The functionality may be altered (as in the user
> cannot enter any data) but how that is presented to the User Agent
> (browser) I am pretty sure that can be customised in 99% of use cases -
> as its only author defined styling or presentation information and does
> not interfere with the forms function or mode. Unless, due to some bug
> it can't (which is always a possibility).
> 
> HTH
> 
> Josh
> 
> 
> 
> 
> ********************************************************************
> 
> NOTICE: The information contained in this email and any attachments 
> is confidential and may be privileged.  If you are not the intended 
> recipient you should not use, disclose, distribute or copy any of 
> the content of it or of any attachment; you are requested to notify 
> the sender immediately of your receipt of the email and then to 
> delete it and any attachments from your system.
> 
> NCBI endeavours to ensure that emails and any attachments generated 
> by its staff are free from viruses or other contaminants.  However, 
> it cannot accept any responsibility for any such which are 
> transmitted.  We therefore recommend you scan all attachments.
> 
> Please note that the statements and views expressed in this email 
> and any attachments are those of the author and do not necessarily 
> represent the views of NCBI
> 
> 
> ********************************************************************
> 
> 
> 
> 
> _______________________________________________
> Irl-dean mailing list
> Irl-dean at list.eeng.dcu.ie
> http://list.eeng.dcu.ie/mailman/listinfo/irl-dean
> 
> 
> ************************
> 
> This message has been delivered to the Internet by the Revenue Internet e-mail service (OP)
> 
> *************************
> 
> _______________________________________________
> Irl-dean mailing list
> Irl-dean at list.eeng.dcu.ie
> http://list.eeng.dcu.ie/mailman/listinfo/irl-dean
> 
> 


********************************************************************

NOTICE: The information contained in this email and any attachments 
is confidential and may be privileged.  If you are not the intended 
recipient you should not use, disclose, distribute or copy any of 
the content of it or of any attachment; you are requested to notify 
the sender immediately of your receipt of the email and then to 
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated 
by its staff are free from viruses or other contaminants.  However, 
it cannot accept any responsibility for any such which are 
transmitted.  We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent the views of NCBI


********************************************************************