Ah, very interesting. Thanks for the tip.
Carlos - space with s to save it. Then go modify said piece of
code in keyword I guess, find your updated file and load it
again.
----- Original Message -----
From: Marvin <[email protected]
To: BN List <[email protected]
Date sent: Tue, 14 Aug 2012 01:19:17 -0500
Subject: [Braillenote] Form Fields on Web Pages
Someone was having trouble with a capcha on the twitter page.
I've never seen this page myself, but I've had similar issues in
the past. Amazon's full site has a problem like this one when
you go to sign into your account. The password field,
and the radio buttons and other things like the sign in button
appear, but the email field does not. I eventually figured out
that some authors of pages like to use non-standard form field
types that computers understand, but our notetakers do not.
In the case of Amazon, the authors used the following code:
<input type="email">. A computer would understand this to mean
that this form field is an edit, or text input, and that
contained within it should be an email address. Of course, the
bn
doesn't know this, so since it doesn't know how to deal with this
field type, it simply ignores it when the page loads. I only
found out about Amazon's email field when I saved a copy of the
sign in page and looked through the html code out of sheer
desperation. When I changed the word email in quotes to the word
text, then loaded my revised copy of the page into keyweb, the
email text input was displayed.
Something similar might be happening on Twitter. But since
it's got a capcha, I fear the issue can't be solved the way I
fixed Amazon's sign in page temporarily. I'm not sure, in fact,
how this issue with the capcha input would be fixed, but I
thought I'd shed some light on the reason why form fields might
not appear correctly on some pages.
P S. It also might help to turn on your scripting. Sometimes
scripts can write parts of a page while it's loading. People are
supposed to let web browsing humans know that a particular part
of their page depends on JavaScript to function, but
that convention doesn't seem to be used very much. I created a
warning message within my playlist shuffler because you apex
users can disable your scripting option. This would make the
utility completely inoperable when it loads, so a page
displaying a message loads when scripting is disabled. When the
page is refreshed after scripting is back on, the application
performs as it should, and this message isn't displayed.
We mPower users can't disable scripting yet, but once I became
aware that other people can do this, I thought it only courteous
to place a <noscript> ... </noscript> section in my utility.
Sorry for the long message. I just wanted to make sure my
fellow bn users can understand what I'm trying to convey here.
So in short, if you can read html code, try saving a copy of the
Twitter page and looking at its code. If nothing springs
out at you, try enabling scripting if it was turned off and see
if the form shows a capcha field when you refresh the page. May
the Force be with you.
___
Replies to this message will go directly to the sender.
If your reply would be useful to the list, please send a
copy to the list as well.
To leave the BrailleNote list, send a blank message to
[email protected]
To view the list archives or change your preferences, visit
http://list.humanware.com/mailman/listinfo/braillenote
___
Replies to this message will go directly to the sender.
If your reply would be useful to the list, please send a
copy to the list as well.
To leave the BrailleNote list, send a blank message to
[email protected]
To view the list archives or change your preferences, visit
http://list.humanware.com/mailman/listinfo/braillenote
