[jawsscripts] Re: Object/element identification in html land? was The problematic highlight bar non-reading of an HTML-based "dropDown," that isn't identified as an editCombo box?

  • From: "Geoff Chapman" <gch@xxxxxxxxxxxxxxxx>
  • To: <jawsscripts@xxxxxxxxxxxxx>
  • Date: Thu, 5 Dec 2013 08:49:19 +1100

Stefan.

On a quick sideNote to this incredibly enriching and revelatory discussion,
amazingly, (re timing),  another client of mine rang me just last night, 
asking me why, when he goes to a particular point on a new website he's 
wanting to view, Jaws says, "application mode on," and he found that all his 
normal quickKeys etc, weren't working!  Without his having turned on Forms 
mode to interface with the browser directly,and with autoForms mode disabled 
globally as his mormal default.
Now I'd never before heard of such a thing as "application mode," and, sure 
enough, pressing NumPad plus, echoed, "PCCursor," not "Virtual PC", as I 
would've expected.
IN addition, further experimentation with jaws+Zed, sure enough, rendered 
not the normal two toggle states of Virtual Cursor on/off that I'd 
previously been aware of, but three!:
(from poor memory: something like Virtual cursor off, Application mode on, 
and Virtual cursor on.
Now: Is this exactly the type of behaviour then that you're referring to 
below?  Is aria somehow on his site, automatically turning on some mode 
analogous to forms mode being active in jaws?  And is it viewed identically 
by jaws as a, "IsFormsModeActive," state?
I'd sure never heard of/seen this before.

Now, returning to the primary issue at hand for me, with this Edit/ListView 
control not auto-reading as jaws alters the highlight, but rereading the 
EditBox continuously as arrows are pressed,
Whilst when I next have access to the system, which may not be till next 
week at this point, so I will have to somehow resurrect this discussion 
again when I can do more testing,
But the additional totally wierd issue I didn't bother reporting to the 
list, was, that we tested these controls with jaws, with Virtual cursor set 
to off with jaws+zed, in both FireFox and Chrome browsers.  And we 
discovered something even more odd!
When arrowing up and down in the dropdown list, Jaws causes the highlight 
bar to jump two,  items, rather than one, every time a single arrowPress is 
detected!
Totally crazy! of course what I didn't remember to test, was doing a 
passThrough first, before each Arrow press, to see if this caused normal 
behaviour,
however, we absolutely confirmed that when jaws wasn't loaded, in those 
browsers, we were getting normal, one item highlight movement per single 
arrow press, behaviour, as expected.
Whereas in Internet explorer 10, with same conditions, we're seeing normal 
behaviour in this regard.

So, if we were to get the employee to use another browser, we'd have this 
issue to work around as well!

Plus the fact that in Firefox, I think v24, heaps of things that are 
actually links, or clickable, just don't identify as such at all!
they just read as normal text out of the box, giving the user no clue of 
their clickable/spaceBar pressing status to activate.

There was a couple other odd behaviours re the wrong things getting selected 
upon pressing spacebar on them in Firefox or chrome too, that gave me some 
reason for pause with those browsers, plus the really problematic fact (for 
me anywayz,) that I'm pretty sure the Jaws Cursor couldn't read anything at 
all onScreen in either of those UI's in those browsers.

So at this stage, I'm thinking I'm probably wanting to stick with IE, given 
that it seems to have the most robust support from jaws in a few imporrtant 
areas.

However I certainly appreciate you letting us know about this additional 
plugin, and it will certainly be instructive to see what Scott manages to 
pull out of that approach for his own individual application.

Although I guess we begin to run into different kinds of problems, would we 
not?  if we start to rely on solutions that are browser dependent, and 
presumably third party dependent also re the plugin developers,
on top of the Screen-reader in the mix as well?
Which upon first flush I would've thought would probably remain the most 
static, so far as provision of solutions for an individual user are 
concerned in a given environ?

This all seems to me, incredibly important though, since, do correct me if 
I'm wrong, but it seems that more and more corporate environments are moving 
into this kind of cloud-based/Browser UI front end paradigm,
Rather than local OldSchool application Interfaces.
Is this other's interpretation as well?


----- Original Message ----- 
From: "Stefan Moisei" <vortex37@xxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Thursday, December 05, 2013 6:38 AM
Subject: [jawsscripts] Re: Object/element identification in html land? was 
The problematic highlight bar non-reading of an HTML-based "dropDown," that 
isn't identified as an editCombo box?


> What I don’t understand is why do you have to be aware of what state jaws
> forms mode is in?
> There are accessible web apps which are not contextually aware of this, 
> and
> they are working. Basically, what they do is they automatically switch 
> forms
> mode on if they require direct keypresses. They do this via aria, which is
> sort of an accessibility API for html.
> Besides this, I'm happy this has proven useful. I know this stuff is
> theoretically possible, but I haven't messed with it at all. So, please
> share the code if you manage something, I think it will be very useful for
> me and Jeff, and hopefully other list members too.
> Thanks.
> -----Original Message----- 
> From: Scott Huey
> Sent: Wednesday, December 4, 2013 7:53 PM
> To: jawsscripts@xxxxxxxxxxxxx
> Subject: [jawsscripts] Re: Object/element identification in html land? was
> The problematic highlight bar non-reading of an HTML-based "dropDown," 
> that
> isn't identified as an editCombo box?
>
> I'd been doing all my scripting with Internet Explorer, I actually had no
> idea that Firefox had a direct Javascript injector add-on available. I've
> been experimenting with building a COM visible IExplorer BHO to perform a
> similar role (specifically to attach DOM event handlers and throw the 
> events
> to JAWS own API), but with minimal success (I'm not that much of a C++
> programmer). If Greasemonkey can be maneuvered to do so, that may 
> definitely
> be the superior approach from every angle imaginable. I've had success
> attaching event handlers within the JAWS scripts using JAWS own COM 
> Attach
> function with limited success, but it only works at the Document level and
> only during the bubble phase, which limits the handling to events which
> bubble all the way up. Direct Javascript handlers would be able to drill
> down as deep as being aware of the straight Index Change on the dropdown
> menus.
>
> It'll still require some JAWS scripting to drive the process, of course,
> since the Plugin could never be contextually aware of what JAWS' state and
> virtual buffer contents are. But I think there might be some serious gain 
> to
> be had hybridizing the approach to allow the "lifting" to be handled by a
> combination of browser plugin and JAWS script rather than pure JAWS script
> alone.
>
> I'm actually going to grab myself a copy of that add-in and do some
> experimenting with the web app I've been working on here right this 
> second!
> Thanks for the bringing that suggestion into the conversation, Stefan, it
> may be downright  paradigm shifting to both Geoff's project and my own!
>
>
> -----Original Message-----
> From: jawsscripts-bounce@xxxxxxxxxxxxx
> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Stefan Moisei
> Sent: Wednesday, December 04, 2013 11:24 AM
> To: jawsscripts@xxxxxxxxxxxxx
> Subject: [jawsscripts] Re: Object/element identification in html land? was
> The problematic highlight bar non-reading of an HTML-based "dropDown," 
> that
> isn't identified as an editCombo box?
>
> I agree with Jeff, this is valuable info. I didn't know jaws can work so
> well with the dom.
> I'd like to introduce an alternative solution in this scenario, i.e.
> scripting web apps.
> There is an extension for firefox, and chrome too, I think, that can
> manipulate the dom. Scripts for it are written in javascript. It's called
> GreaseMonkey. In my view, it is more appropriate for this kind of things,
> because it supports dom events, works with all screen readers, plus it
> supports the other things Scott said jaws doesn't support. Of course, this
> has disadvantages too, the biggest one being that it works on firefox and
> maybe chrome, but not IE.
> Example scripts can be found on userScripts.org. Among others, 
> accessibility
> scripts have been developed for facebook, gitHub and google docs.
> -----Original Message-----
> From: Scott Huey
> Sent: Wednesday, December 4, 2013 5:20 PM
> To: jawsscripts@xxxxxxxxxxxxx
> Subject: [jawsscripts] Re: Object/element identification in html land? was
> The problematic highlight bar non-reading of an HTML-based "dropDown," 
> that
> isn't identified as an editCombo box?
>
> Personally, I think the ClassName of an HTML object is a reasonable point 
> to
> anchor validation checks. "Class" as an HTML attribute is effectively
> arbitrary, but in my experience (from the outside looking in, mind you) is
> that the existence of a class attribute is more or less always indicative 
> of
> the web tool being created using a specific tool or web developer kit to
> produce the content
>
> Assuming we're talking about "Objects" in this context as HTML DOM
> components, then I can point you to the source I got my own crash-course 
> on
> the subject. W3schools.com came up on my initial google search looking for
> basic web  coding information, and they have a beginner guide to DOM
> manipulations at http://www.w3schools.com/jsref/dom_obj_all.asp . It's
> written with Javascript  in mind, but what I discovered very quickly was
> that once you have an object reference to the Document in JAWS (which is
> where all my code snippets used IEGetCurrentDocument() to produce an oFoc
> object), every single one of the basic manipulations works pretty much the
> same way as it would be written for JavaScript. The only limitations I've
> found so far are that JAWS cannot accommodate chaining methods of methods
> together as well as it seems Javascript can, and it has issues with data
> typing errors. In the former, Javascript can handle
> "Document.getElementByID("id").firstChild.nextSibling.ID" to ret
>  urn a value, but even if JAWS doesn't blow up with some variant of an
> "expected A , not B" compiler error, it fumbles the return and the code 
> you
> might be using with that expected return doesn't work properly. In the
> second, JAWS throws periodic  data type mismatch compiler errors with the
> returns of the DOM methods if you try to use a return as part of certain
> statements (i.e. even though the method "element.tagName" returns a 
> string,
> JAWS will complain about typing if you try to concatenate it with another
> string as part of a variable assignment).
>
> Quick heads up, the w3schools site isn't particularly well-designed for
> efficient Screenreader browsing, though I wouldn't categorize it as
> offensively inaccessible. There's just a large, panel bar with "chapter"
> quick links which you'll need to drill down through before reaching the 
> main
> content of current "chapter" on the page. There's also a good solid source
> in the Mozilla Developer Network
> (https://developer.mozilla.org/en-US/docs/DOM) which I find myself
> referencing periodically.
>
> The usage of the period as part of the assignments is actually a critical
> syntactic element of the statement. In Object Oriented Programming, the
> Objects themselves can contain full blocks of processing code, and have
> system resources of their own assigned with which they can execute these
> functions. In Object Oriented Programming, what we're doing would be 
> called
> a "invoking" a "method", which conceptually can be likened to JAWS running 
> a
> Function which JAWS does not own or understand, by way of requesting the
> Object to do so and then hand JAWS the return value.  So in one of the 
> code
> snippets I presented earlier, the line...
>
> let oFoc = oDocument.getElementByID(sElementID)
>
> ... is actually instructing JAWS to instruct the Document Object of the 
> web
> browser itself (which JAWS has a reference to in oDocument) to run an
> internal process to find an element using the string sElementID, which 
> JAWS
> passes. In the case of this method (getElementByID), the Document returns 
> a
> "Node" Object, which we're assigning to oFoc in the  JAWS, and that Node 
> has
> its own methods and properties which we can manipulate.
>
> As to the second question, you might need to experiment with it. In the
> context of my code, the user is assumed to be switching between VirtualPC
> and Forms mode due to the raw text content of the pages they need to
> navigate being important (it's a Call Center script program, so there's
> paragraphs of text reminders for speaking interspersed with only periodic
> controls). I'm not sure, but I believe turning OFF the virtual cursor will
> alter the states in regards to IsFormsModeActive()  as JAWS internally
> understands it. In that case, you probably could use a check for
> IsPCCursor() instead. Easy enough to test, I'd suggest just making a 
> simple
> script (maybe even tie it to the FocusChangedEvent) with a test to the 
> tune
> of "IF IsFormsModeActive() THEN Beep() ENDIF"
>
> In the context of your initial question, I'd suggest abandoning the idea 
> of
> trying to capture the selected item with custom highlighting  entirely. 
> JAWS
> is just too unreliable with web content when it comes to formatting, and 
> in
> particular color coding. I have yet to run into a single case where
> Coloration in a web app is NOT the result of a stylesheet fragment or
> assignment via runtime javascript code (which confounds the JAWSCursor), 
> and
> someone submitted a comment on this list a bit back where they noted that
> they'd found JAWS was generating RGB values for HTML BACKWARDS (as in
> "BGR"). I'm having trouble finding it, I just remember the conundrum as 
> very
> odd, so I apologize to the thread's creator that I cannot cite by name. In
> most cases I've seen, rich internet applications store their selection
> choices for lists/dropdowns somewhere outside the main body content
> (basically a hidden list which the combobox references either front- or
> backend). I'd start by opening the drop
>  down, selecting any available option, and making note of the text 
> content.
> Then, search the page source for that exact phrase. If your application
> follows the pattern I've seen most, there will be a list, table, or 
> possibly
> a div block (probably somewhere deep near the bottom) which contains that
> phrase plus all the other options in the dropdown. The pattern I've seen 
> in
> tools I've worked with is that a web app often applies selection 
> highlights
> by hooking a CSS style to something it changes in the hidden section as 
> the
> selection changes. If you've found a list with the options, compare the
> nodes which contain the unselected options to the node which contains the
> selected one (be sure to check their parents as well, if they're nested, 
> all
> the way back to the common ancestor). Something may jump out at you as
> different (usually a Class but it might be contained as a Style, Name, or
> Value as well), and if you can find that you'll have the key to the
> solution. All you'll need t o do from there is hook the JAWS functions for
> next and previous selection,
>  and include a subroutine that will hunt down the DOM element in that
> list/table/section based on that unique attribute the CSS is hooking. 
> Then,
> you can assign it a reference, and pull back its text content with the
> innerText property so it can be spoken (i.e. SayMessage(OT_MESSAGE,
> oSelected.InnerText) ).
>
>
>
> -----Original Message-----
> From: jawsscripts-bounce@xxxxxxxxxxxxx
> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Geoff Chapman
> Sent: Tuesday, December 03, 2013 9:53 PM
> To: jawsscripts@xxxxxxxxxxxxx
> Subject: [jawsscripts] Re: Object/element identification in html land? was
> The problematic highlight bar non-reading of an HTML-based "dropDown," 
> that
> isn't identified as an editCombo box?
>
> Oh my goodness Scott! This is all simply amazing stuf! Thank you so so so
> much for all the energy and time you've put into sharing all of this below
> to assist me!
> absolutely incredible!
> Wow!
>
> It'll certainly take a little further digesting/sifting, for I'm
> unfortunately not a really experienced Scripter myself, and I can see, (as
> ai feared it would be,) that this is quite comprehensive and involved
> coding, at least for my experience level.
> But I can't tell you how much I appreciate you having shared all these 
> code
> segment examples!  Sooo helpful!
>
> OK so I'm a bit torn here, and not sure exactly which way to jump re next
> protocol steps. In the sense that, I sooo know what it feels like, when 
> you
> give your all, and put in a whole bunch of time/energy into trying to help
> someone out, only to find that it ends up entangling you in even more
> undesired spoon-feeding energy/work, when the person comes back with 
> further
> basic questions about what you've already considerably spent yourself in
> putting out there! :( :)
>
> So, If you'd like to have a break and let someone else perhaps have a shot
> at answering the below, please feel totaly free to do that.  As the last
> thing I wanna do is to engender that feeling of mental tedium/burden
> described above.
> :)
>
> However, unfortunately I do have a couple of what are first really basic
> queries I know, in relation to the syntax of working with objects as your
> code does below.
>
> Then, after getting a handle on this, I feel I'm gonna have to glean a
> little more in-depth knowledge, on understanding, let alone effectively
> working with, the innards of html object element information, such as 
> class,
> TagName, and style - etc, before I'm gonna have a hope of getting to my
> solution; if it turns out I need a scripting solution, which it's 
> certainly
> looking unfortunately like it might be the case so far. :(
>
> I presume from a small investigative study of your below, that you feel
> Class is a reasonable criteria validator to be utilizing for a conditional
> behaviour modification, "If ... then",  check?
>
> So, I guess the first thing to ask is, to negate your having to tediously
> answer such low-level queries as to exactly how/when  the period is meant 
> to
> be used, when coding involving objects, which at present, never having 
> tried
> to work with objects before I'm totally unfamiliar with, might you/anyone
> have any tips on where i might go, to get a bit of a crashCourse tutorial 
> on
> the basics of working with Objects?
> Specifically, the usage of the period in the middle of names? Which I
> haven't seen before?
>
> secondly, Assuming the Virtual Cursor is turned completely off with
> Jaws+Zee, this would presumably look the same to jaws as a
> "FormsModeIsActive" state.  Would that be correct?
> Because it looks like so far the most effective way for this user to
> traverse this form, and drop down the lists on each of these boxes with 
> the
> downArrow key, is if we disable Virtual cursor, rather than him flip in 
> and
> out of Forms mode, (as we've set it to manual at this point.)
>
>
> Third, Would you feel up to sharing any more of your obviously 
> considerable
> experience, as to how you might bring about the natural jaws behaviour 
> we're
> shooting for here in such a situation? Assuming I can narrow down these
> objects reliably, so that I can put specific alternate behaviour for
> DownArrow/UpArrow/SayLine, when these particular elements gain focus?
>
>
> Thanks again so much Scott for what you've already done below.
> It's sure given me a light into this I didn't know existed.  So I hope it 
> is
> helping others to know/grow as well.
>
> Regards
> Geoff C.
> ----- Original Message -----
> From: "Scott Huey" <shuey@xxxxxxxxx>
> To: <jawsscripts@xxxxxxxxxxxxx>
> Sent: Tuesday, December 03, 2013 4:12 AM
> Subject: [jawsscripts] Re: Object/element identification in html land? was
> The problematic highlight bar non-reading of an HTML-based "dropDown," 
> that
> isn't identified as an editCombo box?
>
>
>> I've been building some scripting for an AJAX based web application,
>> which includes specific behavioral modification based on conditionals
>> of HTML element type as you're describing.  In the context of my
>> scripting, I was co-opting the arrow key navigation to behave uniquely
>> when the "focused"
>> section of the page was built with specific components which did not
>> behave "naturally" (i.e. the bane of my existence, the "ajax__tab_xp
>> ajax__tab_container ajax__tab_default" interactive tab container DIV
>> object). It took me about a couple days to sort it all out, but in the
>> end I was able to build out a nested conditional statement which could
>> accurately check for details of the object in question. The steps
>> required are radically different depending on which cursor is active.
>> In the context of the web app I'm working with, JAWS and Invisible
>> Cursors return wildly inaccurate data, so I was able to constrain my
>> cases to a binary choice between either the PC Cursor ("IF
>> IsFormsModeActiv
>> e() THEN") and the Virtual Cursor ("IF isVirtualPCCursor() THEN").
>>
>> If the active cursor is the PC cursor (i.e. Forms Mode is active), the
>> process is a relatively straightforward one using pure Document Object
>> Model (DOM) level interactions. The DOM contains a method for
>> instantly returning the current object with focus,
>> "document.ActiveElement", which can then be queried directly for its
>> specific details. JAWS code to retrieve the information would look as
>> follows:
>>
>> /* --- Start Code Segment --- */
>> Var object oDocument, object oFoc, string sElementID let oDocument =
>> IEGetCurrentDocument() let sElementID = oDocument.activeElement.ID let
>> oFoc = oDocument.getElementByID(sElementID)
>> ; From here, I could now manipulate the object directly further in the
>> scripting, including directly extract data about its class, tag, and
>> style.
>> /* --- End Code Segment --- */
>>
>> If the VirtualPC cursor is active and the user is traversing the OSM,
>> I think we're stuck using the GetElementDescription function and
>> extracting the relevant substring from its return. Conceptually, I'm
>> absolutely certain that GetElementDescription itself is using more
>> targeted sub-functions to find the individual parts it returns (id,
>> class, etc., which it then concatenates together), but I haven't found
>> any documentation indicating what they might be so I've relied on
>> delimiting the return using the newline ("\n") character as the
>> delimiter. The results are fairly reliable, under the assumption that
>> elements of interest will ALWAYS have the attribute I'm checking (i.e.
>> when I check for IDs, I already know in the specific web tool I'm
>> working on that everything with text content drawn into the OSM has a
>> programmatically assigned ID value in the DOM). For this, the code
>> looked something like
>> below:
>>
>> /* --- Start Code Segment --- */
>> Var string sDelimited, int iIndex, object oFoc, object oDocument Let
>> oDocument = IEGetCurrentDocument() let sDelimited =
>> GetElementDescription (1, FALSE) ; Returned only information regarding
>> the specific element, as Ancestor data is here irrelevant.
>> let iIndex = StringSegmentIndex (sDelimited, "\n", "id=", False)
>> ;Delimit the string by the NewLine character, return the index of the
>> one for the ID via the tag "id="
>> let sDelimited = StringSegment (sDelimited, "\n", iIndex) ;Pare down
>> the string to just the single segment let sDelimited =
>> StringReplaceSubstrings (sDelimited, "id=", "") ;At this point,
>> sDelimited is now purely the ID let oFoc  =
>> oDocument.getElementByID(sDelimited)
>> ; From here, I could now manipulate the object directly further in the
>> scripting, including directly extract data about its class, tag, and
>> style.
>> /* --- End Code Segment --- */
>>
>> A basic example adapted from my existing code, where I would be trying
>> to extract the "current element's" Class for the purposes of a
>> validation check, altogether looks like so. For reference, oDocument
>> was set with IEGetCurrentDocument much higher in the function.
>>
>> /* --- Start Code Segment --- */
>> IF FormsModeActive() Then
>> Let sClass = oDocument.activeElement.className ELIF
>> IsVirtualPCCursor() Then Let sDelimited = GetElementDescription(1,
>> FALSE) ; Returned only information regarding the specific element, as
>> Ancestor data is here irrelevant.
>> Let iIndex = StringSegmentIndex(sDelimited, "\n", "class=", False) Let
>> sClass = StringSegment(sDelimited, "\n", iIndex) Let sClass =
>> StringReplaceSubstrings(sClass, "class=","") Else ;Logic in this
>> script assumed the JAWS and Invisible Cursors represent an invalid
>> state (as they return anomalous results), so this branch simply did
>> cleanup and then called the original implementation of the overridden
>> script EndIF
>> /* --- End Code Segment --- */
>>
>> From that point, I would use sClass as part of an extended ELIF block,
>> essentially working as a SELECT CASE construct, to branch the
>> behaviors depending on the specific type of element on which the User
>> had (virtual) focus. I think it fairly robust, in that my
>> implementation has survived stability and reliability testing on the
>> web-tool I've designed it for.
>> That said, it's a scripting solution for a web tool we host in house.
>> So while it's not one we wrote ourselves (if it was, I would have made
>> it conform to WCAG so scripting wouldn't be necessary at all), it's on
>> a server which won't be updated without our consent. I've admittedly
>> designed around a specific edition of a designer tool, so YMMV of
>> course but I also wouldn't recommend taking this sort of approach with
>> any hosted tool that could be redesigned without warning. Just about
>> any attribute you could reference for a Rich Internet Application is
>> arbitrary in its specific string. The only things I would say really
>> end up being set in stone (to the point that you could define them
>> statically in a JAWS script) as far as a Web App is concerned are the
>> flat Tag Names, and of course ARIA markups. Theoretically if there are
>> ARIA markups in your web application, then scripting shouldn't be needed.
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: jawsscripts-bounce@xxxxxxxxxxxxx
>> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Geoff Chapman
>> Sent: Sunday, December 01, 2013 4:42 PM
>> To: jawsscripts@xxxxxxxxxxxxx
>> Subject: [jawsscripts] Object/element identification in html land? was
>> The problematic highlight bar non-reading of an HTML-based "dropDown,"
>> that isn't identified as an editCombo box?
>>
>> Another perhaps even more basic question related to my issue though
>> that occurs.
>>
>> In Html land, where it seems we're not talking about identifying
>> certain so-called windows, at the detection of which we might wish to
>> alter certain default behaviour, but rather, elements? or Objects?"
>> How would one go about even setting up conditional statements to check
>> if we were focused on a certain object or element, like these
>> particular edit/list-box combo controls, to even introduce a solution?
>> Once we've come up with one that works anyway?
>>
>> E.g. in the element information, part of which I'll rePaste below, We
>> read things like Class, and ID, and Tag DIV, etc.
>> So is it possible in Script land, to somehow code up conditional
>> statements that might look for these identifiers, and to thus insert
>> behaviour change when located?
>> How might one even begin to go about doing this?
>> Is such methodology in the least reliable/robust in a browser based
>> situation such as this?
>>
>> Or, if too onerous to answer directly, does anyone know just where I
>> might even begin to go for study of such a situation where this might
>> be being done somewhere already?
>>
>> Here's a little code from the original element information on this
>> particular control:
>>
>>
>>
>>>> Element Information:
>>
>> Tag INPUT has 7 parameters:
>>
>> autocomplete=off
>>
>> class= x-form-text x-form-field  x-form-focus
>>
>> id=par-1C05555973514DF39BE96CF44694A3B2-d
>>
>> size$
>>
>> style
>> tabindex!002
>>
>> type=text
>>
>> MSAA Role*
>>
>>
>> Tag DIV has 3 parameters:
>>
>> class=x-form-field-wrap x-form-field-trigger-wrap
>> x-trigger-wrap-focus
>>
>> id=ext-gen437
>>
>> style=
>>
>> Tag DIV has 3 parameters:
>>
>> class=x-form-element
>>
>> id=x-form-el-par-1C05555973514DF39BE96CF44694A3B2-d
>>
>> style=
>>
>> Tag DIV has 3 parameters:
>>
>> class=x-form-item
>>
>> id=ext-gen434
>>
>> tabindex=-1
>>
>> Tag DIV has 3 parameters:
>>
>> class= x-request-column x-request-column-out x-form-label-top x-column
>>
>> id=ext-comp-1504
>>
>> style=
>>
>> ----- Original Message -----
>> From: "Jim Snowbarger" <Snowman@xxxxxxxxxxxxxxxx>
>> To: <jawsscripts@xxxxxxxxxxxxx>
>> Sent: Saturday, November 30, 2013 2:53 PM
>> Subject: [jawsscripts] Re: The problematic highlight bar non-reading
>> of an HTML-based "dropDown," that isn't identified as an editCombo box?
>>
>>
>>> Does anybody know what window jaws will search for a custom highlight?
>>> That
>>> isn't a applicaition-wide search, is it?
>>> Will it not search if a normal caret can be found?
>>> If not, how could one make it ignore the caret, and use highlight
>>> searching only.
>>>
>>> ----- Original Message -----
>>> From: "Geoff Chapman" <gch@xxxxxxxxxxxxxxxx>
>>> To: <jawsscripts@xxxxxxxxxxxxx>
>>> Sent: Friday, November 29, 2013 9:08 PM
>>> Subject: [jawsscripts] Re: The problematic highlight bar non-reading
>>> of an HTML-based "dropDown," that isn't identified as an editCombo
>>> box?
>>>
>>>
>>> Hi everyone.
>>>
>>> NO joy with any of the suggestions tried so far, except for Arder's
>>> below.
>>> haven't gotten to try that one yet, so keep any other suggestions on
>>> this coming.
>>>
>>> Jackie when I get a remote login to this system, I'll be able to
>>> trial a few more things like HSC's GetColorAtPoint functionality, as
>>> opposed to the
>>> Jaws+TopRow5 Get TextColor Foreground/Bakground, the dude I'm working
>>> with
>>> was certainly surprised when what he thought was a blue highlight
>>> bar, got defined as Grey13 on lavender.
>>> Although I thought lavender was a type of blue, but ... hey, what
>>> would I know.
>>>
>>> Jim tested with the Jaws cursor tucked firmly out of the way, and
>>> invisible cursor on highlighted text just with focus etc, still
>>> thinks it's grey13 on Lavender, whereas the non-highlighted text in
>>> the list is identified as
>>> Grey13 on white. so we tried setting the custom highlight as anything
>>> on Lavender, since it seemed to us that it was maybe the background
>>> that was doing the highlighting, but, still no joy. jaws doesn't
>>> track it as highlight is moved up and down.
>>> Sigh.
>>> ----- Original Message -----
>>> From: "Artur Räpp" <rtr@xxxxxxxxx>
>>> To: <jawsscripts@xxxxxxxxxxxxx>
>>> Sent: Friday, November 29, 2013 5:36 PM
>>> Subject: [jawsscripts] Re: The problematic highlight bar non-reading
>>> of an HTML-based "dropDown," that isn't identified as an editCombo
>>> box?
>>>
>>>
>>>> Hello,
>>>>
>>>> On a webpage I found following solution with a "edit-combo"
>>>>
>>>> I moved to edit field (edit part of the edit-combo), turned off the
>>>> virtual cursor, typed some letter, pressed once down arrow, pressed
>>>> tab once, landed on the listbox part and then moved down with down
>>>> arrow.
>>>> After I found what I needed, I turned virtual cursor again on.
>>>>
>>>> On another such HTML editcombo I didn't found any solution and
>>>> copied the choices into a file and copi-pasted from the file the
>>>> right choice into edit field. With the full text system chose the
>>>> right choice. The coices were static. To get the choices, I used
>>>> ins+ctrl+shft+f1 keyboard command (Advanced Element Information).
>>>>
>>>> my 0.01$.
>>>>
>>>> Artur
>>>>
>>>> 29.11.2013 2:00, Geoff Chapman kirjutas:
>>>>> Hi Scripters.
>>>>> Ok, in relation to my query the other day, about a particular
>>>>> so-called "drop-down,"type element on a particular client's
>>>>> workPlace site that Jaws will not handle correctly, I now have more
>>>>> information about this, and would very much appreciate anyone's
>>>>> views on where I might even start to solve this problem, as it's a
>>>>> dealBreaker for this poarticular employed person, re being able to
>>>>> do his job on the new system the company is rolling out in February.
>>>>> It's a bit of a lengthy query, but I'd appreciate those who're
>>>>> able, to stick with me whilst I try and elaborate what, I, think is
>>>>> so far going on here.
>>>>>
>>>>> Ok So, first, this is an html-based system, and everything else
>>>>> here seems to be beautifully accessible, even the fields are all
>>>>> labelled properly.
>>>>>
>>>>> Second, I've turned off AutoForms mode, as I find this mode very
>>>>> problematic and just annoying to navigate, after years of using the
>>>>> manual forms mode modality.
>>>>> Also trying to eliminate as much of the so-called automatic smarts,
>>>>> as possible, to eliminate unknown and possibly erroneous behaviours
>>>>> etc.
>>>>>
>>>>> However there's this one particular totally problematic
>>>>> control-type/element, which consists of initially what Jaws
>>>>> identifies as a straight ahead, edit, box.  However, this
>>>>> particular element, operates in practise, actually, more like what
>>>>> I understand to be often defined by jaws as an "EditCombo",
>>>>> control.
>>>>> Whereby, as you start typing into the edit part of the field, a
>>>>> "drop-down" list appears,matching the entries it finds related to
>>>>> the letters in the text query entered so far.
>>>>>
>>>>> (Additionally, the field visually contains a little downpointing
>>>>> graphical triangle, which sighted users may click on to drop down
>>>>> the unfiltered list, and visually view it that way, if preferred,
>>>>> with no text query filtering applied.) But which is, not, activated
>>>>> at all by pressing Alt+DownArrow, as one would expect if Jaws
>>>>> handled the element as a proper EditCombo.
>>>>>
>>>>> Now. The major problem is, that even though pressing downArrow,
>>>>> does start to navigate the entries in this field, placing what it
>>>>> identifies as a Grey13 on Lavender highlight highlight color over
>>>>> each selected entry, Jaws does not read this highlight,, because
>>>>> it's locked into the fact that there's presumably still an iBeam
>>>>> edit cursor sitting in the edit box the whole time. So it just
>>>>> keeps reReading, "Edit," plus whatever the current text query value
>>>>> has been typed in, and is thus populating that edit field, upon
>>>>> each arrow press.
>>>>>
>>>>> now another perhaps relevant aspect to understand about this
>>>>> particular controlType, as compared to some others I've seen, which
>>>>> although not identifying as EditCombos either, appear to behave in
>>>>> this very way, but which jaws does quite happily read, Is thatt in
>>>>> our version, the control doesn't immediately populate the edit
>>>>> field, with the entire selection one navigates to with the arrow
>>>>> keys.
>>>>> Whereas, the ones that jaws does happily appear to read properly,
>>>>> do seem to do this.
>>>>> Therefore, in those fields where jaws does identify what one has
>>>>> arrowed to, it's probably not doing so by reading/tracking the
>>>>> highllight bar, but simply by reading what's appearing at the edit
>>>>> cursor.
>>>>>
>>>>> My first thought was to try and reClass the window, but, this
>>>>> didn't have any good effect, since of course as ai realized later,
>>>>> what I want to do here, is reClass, as far as Jaws is concerned,
>>>>> these individual elements, which are probably not the same as whole
>>>>> windows anyway.
>>>>> When I looked at the class of the window in focus, it just showed
>>>>> some basic high-level seemingly irrelevant class  such as Class =
>>>>> MozillaContentWindowClass etc.
>>>>>
>>>>> So no joy there.
>>>>>
>>>>>
>>>>>
>>>>> My second thought, was to try and identify the custom highlight
>>>>> color, and assign this as a custom highlight in jaws, hoping to
>>>>> attract it's attention to the fact that it should be checking for,
>>>>> and tracking/reading, anything in that highlight color.
>>>>>
>>>>> However, I have no joy doing that either.
>>>>>
>>>>> putting the jaws cursor on it, it reckons the highlight is Grey13
>>>>> on Lavender, but, yep, this didn't work either.
>>>>>
>>>>>
>>>>>
>>>>> So has anyone got any bright ideas as to what I might try next?
>>>>> Is Custom Highlight tracking even working in jaws15 at present 
>>>>> anywayz?
>>>>> Some way I can tell jaws how to properly handle this type of element?
>>>>> ignoring the edit box cursor, and tracking the highlight bar instead?
>>>>> Below I have included the rather comvoluted, but possibly helpful
>>>>> to someone who may know, element information from the
>>>>> jaws+Shift+f1, whilst over this particular field.
>>>>>
>>>>> Thanks much for any tips!
>>>>> See below for the tech stuff about the elemtn.
>>>>>
>>>>>
>>>>>
>>>>> Element Information:
>>>>>
>>>>> Tag INPUT has 7 parameters:
>>>>>
>>>>> autocomplete=off
>>>>>
>>>>> class= x-form-text x-form-field  x-form-focus
>>>>>
>>>>> id=par-1C05555973514DF39BE96CF44694A3B2-d
>>>>>
>>>>> size$
>>>>>
>>>>> style
>>>>> tabindex!002
>>>>>
>>>>> type=text
>>>>>
>>>>> MSAA Role*
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-form-field-wrap x-form-field-trigger-wrap
>>>>> x-trigger-wrap-focus
>>>>>
>>>>> id=ext-gen437
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-form-element
>>>>>
>>>>> id=x-form-el-par-1C05555973514DF39BE96CF44694A3B2-d
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-form-item
>>>>>
>>>>> id=ext-gen434
>>>>>
>>>>> tabindex=-1
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-request-column x-request-column-out x-form-label-top
>>>>> x-column
>>>>>
>>>>> id=ext-comp-1504
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-column-inner
>>>>>
>>>>> id=ext-gen423
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-panel-body x-panel-body-noheader x-panel-body-noborder
>>>>> x-column-layout-ct
>>>>>
>>>>> id=ext-gen386
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen385
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-panel request-view-category x-panel-noborder
>>>>>
>>>>> id=ext-comp-1503
>>>>>
>>>>> style=
>>>>>
>>>>> Tag FORM has 5 parameters:
>>>>>
>>>>> class=x-panel-body ss-svc-form-body x-panel-body-noheader
>>>>> x-panel-body-noborder x-form
>>>>>
>>>>> enctype=application/x-www-form-urlencoded
>>>>>
>>>>> id=ext-gen184
>>>>>
>>>>> method=post
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen335
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-panel ss-svc-form x-panel-noborder x-form-label-left
>>>>> x-box-item
>>>>>
>>>>> id=ext-comp-1270
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-box-inner
>>>>>
>>>>> id=ext-gen334
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-box-layout-ct
>>>>>
>>>>> id=ext-comp-1272
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-panel-body x-panel-body-noheader
>>>>>
>>>>> id=ext-gen318
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen316
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-panel x-frs-sc-param-form ss-svc-form
>>>>>
>>>>> id=ext-comp-1268
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-panel-body x-panel-body-noheader x-panel-body-noborder
>>>>>
>>>>> id=ext-gen315
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen314
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class= x-panel tab-panel parameters-tpl x-flex-portal-child
>>>>> x-panel-noborder
>>>>>
>>>>> id=ext-comp-1283
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-flex-portal-child-frame
>>>>>
>>>>> id=ext-comp-1284
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-tab-panel-body x-tab-panel-body-top
>>>>>
>>>>> id=ext-gen224
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-tab-panel-bwrap
>>>>>
>>>>> id=ext-gen223
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-tab-panel x-frs-flex-portlet
>>>>>
>>>>> id=ext-comp-1239
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-panel-body x-panel-body-noheader x-panel-body-noborder
>>>>>
>>>>> id=ext-gen208
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen207
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-panel x-frs-flex-portal x-panel-noborder x-border-panel
>>>>>
>>>>> id=ext-comp-1223
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-panel-body x-panel-body-noheader x-panel-body-noborder
>>>>> x-border-layout-ct
>>>>>
>>>>> id=ext-gen206
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen205
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-panel x-panel-noborder
>>>>>
>>>>> id=ext-comp-1227
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-panel-body x-frs-flex-panel-body x-panel-body-noheader
>>>>>
>>>>> id=ext-gen187
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen185
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-panel x-frs-formview
>>>>>
>>>>> id=ext-comp-1222
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-panel-body x-panel-body-noheader x-panel-body-noborder
>>>>>
>>>>> id=ext-gen17
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen16
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-panel x-frs-content x-border-panel
>>>>>
>>>>> id=ext-comp-1002
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-panel-body x-panel-body-noborder x-border-layout-ct
>>>>>
>>>>> id=ext-gen12
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-mc
>>>>>
>>>>> id=ext-gen15
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>>
>>>>> class=x-panel-mr
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>>
>>>>> class=x-panel-ml
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen11
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-panel x-panel-noborder
>>>>>
>>>>> id=WorkspaceFrame
>>>>>
>>>>> style=
>>>>>
>>>>> Tag BODY has 3 parameters:
>>>>>
>>>>> href=https://kfchelp-stg.saasit.com/WorkspaceLoader.aspx?Id=Service
>>>>> Req&Profile=ObjectWorkspace&LayoutName=SDA-YAI&TabId=ext-comp-1101
>>>>>
>>>>> id=main_body
>>>>>
>>>>> rssúlse
>>>>>
>>>>> MSAA Role
>>>>>
>>>>> Tag IFRAME has 8 parameters:
>>>>>
>>>>> class=x-managed-iframe
>>>>>
>>>>> frameborder=0
>>>>>
>>>>> id=ext-gen112
>>>>>
>>>>> name=ext-gen112
>>>>>
>>>>> scrolling=auto
>>>>>
>>>>> src
>>>>> style
>>>>> title=Object Workspace
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-panel-body x-panel-body-noheader x-panel-body-noborder
>>>>>
>>>>> id=ext-gen111
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 2 parameters:
>>>>>
>>>>> class=x-panel-bwrap
>>>>>
>>>>> id=ext-gen110
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-panel x-panel-noborder
>>>>>
>>>>> id=panelext-comp-1101
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-border-panel
>>>>>
>>>>> id=app-frame-body
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-box-item x-border-layout-ct
>>>>>
>>>>> id=app-content-wrapper
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class=x-box-inner
>>>>>
>>>>> id=ext-gen10
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-box-layout-ct
>>>>>
>>>>> id=ext-comp-1003
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-app-content x-border-panel
>>>>>
>>>>> id=AppBody
>>>>>
>>>>> style=
>>>>>
>>>>> Tag DIV has 3 parameters:
>>>>>
>>>>> class= x-app-frame x-border-layout-ct
>>>>>
>>>>> id=BorderWrapper
>>>>>
>>>>> style=
>>>>>
>>>>> Tag BODY has 3 parameters:
>>>>>
>>>>> href=https://kfchelp-stg.saasit.com/Default.aspx
>>>>>
>>>>> id=main_body
>>>>>
>>>>> rssúlse
>>>>>
>>>>> MSAA Role
>>>>>
>>>>> Press ESC to close this message.
>>>>>
>>>>>
>>>>> *****
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Also, today in IE, (haven't tried yet in other browsers) I ran
>>>>> across a Suburb/postcode field, at the below URL, which I wanted
>>>>> you to just eyeball as it
>>>>> *appeared* to work similarly to how I imagine our dropdowns on your
>>>>> site are working? which this one, jaws reads perfectly fine? but am
>>>>> unsure of course of the backEnd element/Javascript running ... etc.
>>>>>
>>>>>
>>>>>
>>>>> It's at the following URL:
>>>>>
>>>>> https://www.oxfam.org.au/my/donate/typhoon-haiyan-yolanda?utm_campa
>>>>> ign=Typhoon_2nd_ask&utm_medium=Email&utm_source=Typhoon_2nd_ask
>>>>>
>>>>>
>>>>> Leaving virtual cursor enabled for the moment, After tabbing to the
>>>>> correct field, Hit enter to turn on forms mode, then type something
>>>>> that will bring up multiple entries in the list, then hit down
>>>>> arrow. Try it in your version of IE?
>>>>>
>>>>> For me here, in IE8, jaws reads each highlighted entry just fine as
>>>>> one arrows up and down in this list,
>>>>>
>>>>> without having to assign any custom highlight colors at all.
>>>>>
>>>>>
>>>>> For interest, though I know it won't mean much to you, here's the
>>>>> backend stuff re the element that Jaws reports when doing a
>>>>> Control+Insert+F1 on that field in IE 8, without forms mode
>>>>> enabled.
>>>>>
>>>>> (note that this Insert+Shift+F1 keystroke doesn't work when either
>>>>> forms mode is enabled or virtual cursor is off, which are
>>>>> effectively the same thing
>>>>> anyway:)
>>>>>
>>>>>
>>>>> Element Information:
>>>>>
>>>>>
>>>>> Tag INPUT has 11 parameters:
>>>>> aria-autocomplete=list
>>>>> aria-haspopup=true
>>>>> autocomplete=off
>>>>> class=ui-autocomplete-input
>>>>> id=suburb_ac
>>>>> jquery172036613851847330175
>>>>> name=suburb_ac
>>>>> role=textbox
>>>>> tabindex!
>>>>> type=text
>>>>> value=EPPING,  NSW,  2121
>>>>> MSAA Role*
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> class=input
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> class=clearfix
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> id=autoggle-au
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> class=form-row
>>>>>
>>>>>
>>>>> Tag FIELDSET has 0 parameters:
>>>>>
>>>>>
>>>>> Tag FORM has 8 parameters:
>>>>> _submit_attached=True
>>>>> accept-charset=utf-8
>>>>> action=https://www.oxfam.org.au/my/donate/typhoon-haiyan-yolanda
>>>>> class=myform form-stacked
>>>>> enctype=application/x-www-form-urlencoded
>>>>> id=donation_form
>>>>> jquery172036613851847330175(
>>>>> method=post
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> class=span11 main-content
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> class=row
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> id=bootstrap
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> class=main-holder
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> id=main
>>>>>
>>>>>
>>>>> Tag DIV has 1 parameters:
>>>>> id=wrapper
>>>>>
>>>>>
>>>>> Tag BODY has 2 parameters:
>>>>> href=https://www.oxfam.org.au/my/donate/typhoon-haiyan-yolanda?utm_
>>>>> campaign=Typhoon_2nd_ask&utm_medium=Email&utm_source=Typhoon_2nd_as
>>>>> k
>>>>> rssúlse
>>>>> MSAA Role
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Press ESC to close this message.
>>>>>
>>>>> __________�
>>>>>
>>>>> View the list's information and change your settings at
>>>>> //www.freelists.org/list/jawsscripts
>>>>>
>>>>>
>>>> __________�
>>>>
>>>> View the list's information and change your settings at
>>>> //www.freelists.org/list/jawsscripts
>>>>
>>>>
>>>
>>> __________�
>>>
>>> View the list's information and change your settings at
>>> //www.freelists.org/list/jawsscripts
>>>
>>>
>>>
>>> __________�
>>>
>>> View the list's information and change your settings at
>>> //www.freelists.org/list/jawsscripts
>>>
>>>
>>
>> __________�
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>>
>> __________�
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>
> __________�
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
>
> __________�
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
> __________�
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
>
> __________�
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus 
> protection is active.
> http://www.avast.com
>
> __________�
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
> 

__________�

View the list's information and change your settings at 
//www.freelists.org/list/jawsscripts

Other related posts:

  1. Home
  2. jawsscripts
  3. Archive
  4. 12-2013