For those who may have a bit of a hearing impairment, let me make
it very clear. In my subject, I'm saying DOM, D O M, not balm,
b A L M. Although some may call DOM the balm. LOL! And here
therefore lies the reason for my post this morning. - I fully realize
that this is somewhat a subjective topic, and that everyone will have
his or her own opinions on the matter. It is therefore my hope, that
you, the reader, have an open and civil mind, and observe this question
from all angles before making your response statement on list. I do not
want to see this grow to a heated war debate. Anyone who would like to
publish this on their website, or wherever is welcome to do so as long
as you give credit back to me.
First off, what is DOM?
DOM, Document Object Model, without getting too technical, is one
way in which assistive technology such as screen readers obtain
information from one's computer screen. When we load a website in our
browser of choice, for example, some screen readers use the DOM
functionality to draw a representation of the content on the
screen.
So, what does this mean to us non-techies?
Put simply, though I am not particularly sure of the exact workflow
which occurs behind the scene, what I can tell you is this. Often times,
more than not, this approach requires the assistive technology sitting
in between the user and the web browser to redraw, as some would say,
the entire HTML content in completion. The reason that the word "redraw"
is used is because essentially, this is exactly what is happening.
Once a website is loaded, a certain amount of memory is allocated
aside where the website in question may be rendered. There are a few
advantages to this, however there are also some huge setbacks.
Beauty and the Beast
One of the advantages which probably appears to be fairly obvious
from an outsider's perspective is that this will allow assistive
technology to use certain methods to gather the web content and then
present the material in an easy, robust, and sensably accessible manor.
As the writer of this post, let me assure all of you... I definitely see
the side of this argument.
Here's a practical example of DOM.
Let's assume, for just a moment, that you have loaded a website in
the browser of your preference, be it Firefox, Internet Explorer,
Chrome, etc.
On this particular page, there are links which visually appear as
horizontal tabs extending across the top of the page. These tabs include
the following:
- Home
- About Us
- Blog
- Shop
- Support
- Contact Us
To fully understand how this works, I encourage you to read the
following part of this e-mail by using your down arrow key, and reading
line by line individually. Here is what you will see. Remember before I
go any further with this, all of these links visually appear as one
strip of horizontal tabs running across the top of the web page.
Link Home
Link About Us
Link Blog
Link Shop
Link Support
Link Contact Us
Here's another example.
You have a short form on a website. This form asks for your first
name, your last name, and your e-mail address. Here's how DOM most
likely would reinterpret this. Again, please read this line by
line.
Please fill out the following form so we may keep in touch.
First name
Edit
Last name
Edit
E-mail
Edit
Submit button
Clear form button.
First example without DOM
Read this line by line, and make sure this window with my message
is maximized before doing so.
Link home, Link About Us, Link Blog, Link Shopt, Link Support, Link
Contact Us.
Second example without DOM
Please fill out the following form so we may keep in touch.
First name Edit
Last name Edit
E-mail Edit, Submit: button, Clear form: Button.
The difference
As you can see in the above four illustrations, the first two
examples were rendered in such that each link/form control was on its
own line. This is why I asked you to read line by line, as doing a
say-all, you never would have most likely caught this. So, in other
words, let's make this really easy in plain english.
Refer back to my very first example where we had the tabs which are
being represented as hyperlinks. As you recall, I said that they all
went horizontally from left to right across the top of the page.
The problem is, DOM renders each element, for lack of better word,
as its own separate item. For this reason, each element is on its own
dedicated line of text. This is why each link is seeming to appear on
its own line by itself. The truth is, these links in all actuality are
not on multiple lines. They are actually expanding across the entire
marginal width of the screen. Are you starting to see where this could
be a potential problem?
The second example is slightly less annoying, however the point
still stands in existance.
We have a form. If you've ever seen how a form generally looks on a
print sheet of paper, you'll note that most form field labels such as
first name, last name, etc. go down the left side of the sheet of paper.
Then, horizontally aligned beside these field labels is the data
value.
For example, I might have a form printed out which I sign for a
Hippa release at my doctor's office. The first field may say, "Name".
Out to the immediate right of this will be either a line, or a box. It
just depends on how the form is designed, but the over all point is,
there will be a second column to the immediate right of where it said,
"First name". This is where I would write, "Christopher (Middle name)
Gilland. Obviously, some of you may know my middle name, but for privacy
sake, I'm not including it here.
Given how the above physical print paper illustration is formatted,
as most forms online or not would be, does it really make sense to have
the form field, then the data directly below? No. It doesn't.
Look at my above second example without DOM. Notice that the edit
box for all three fields is now actually rendering exactly as it would
be visually on the screen. The boxes are to the immediate right of the
fields, on the same line. Doesn't that just naturally feel better in
your mind, and make more sense? It definitely should to most
people.
Finally, we have both the submit, and the clear vbuttons.
Does it make sense to you that they'd both be virtically stacked
one on top of the other? It certainly doesn't to me! In fact, to me, I'd
even go so far as to say it seems absolutely gross! Maybe I am more a
visual learner, but even if I wasn't, this doesn't logically
compute. However, this is exactly how DOM is rendering it... One button,
and one element per line.
Helping the sighted to guide you
So why is this such a vbig deal? Call me a perfectionist, but let's
assume for just a moment that you're on the phone with a customer
service representative. They tell you to click the contact us tab
located in the upper right corner of the page. This would be a very poor
website design, and to any web debvs on here, please for the love of
god, take this in consideration! I can't tell you though how many times
I've seen this. A web designer will put a contact link at the top of the
page which has a form to e-mail them. Further down the page, they have
another contact link within the actual main body's content. The
difference however is, in this second link, though named identically the
same thing, "Contact Us", this second link doesn't direct the visiter to
a contact form, but instead gives a phone number, fax number, and
possibly a postal address. Totally unacceptable in my view! All this
should be consolidated on the one contact page at the top of the screen.
This however still proves my point, and like I said, I've seen this more
times than I could count, and would gbe rich if I had a dollar for every
time I have. OK, so, you now arrow through the page, or do an NVDA find
to locate the Contact link. Heck, you might even do NVDA+F7 to bring up
your links list. And believe me, though I'm directing this more as an
NVDA thing, NVDA isn't the only screen reader which can use the DOM
method. JAWS, for example, is incredibly! and I do mean, incredibly!
notorious for this. Now, think about this a minute with this really
convoluted scanareo regarding the contact link. - How are you going to
know which contact link to press enter on to open the contact form, if
you're in DOM navigation? Exactly! - You won't. It would be hit and
miss.
Now, let's take this same situation without DOM mode.
In this environment, for lack of better word, you would observe
both via audible speech, as well as via braille output if you have a
display, that the first "Contact us" link is on the far right edge of
the screen. You'd know this as you'd see the other links like Home,
About us, Blog, etc. on the same line but to the immediate left before
it. Does this make sense what I'm saying?
The bottom line
Regardless if you choose to use DOM or not is not something anyone
should decide for an individual. If you are coming from a screen reader
like JAWS as I have, you definitely may find turning off DOM navigation
to be extremely awquard at best. I'd even go as far as to say that it
may drive you absolutely crazy at first, and make your web browsing
experience seem dreadful. I would however seriously encourage people to
at least give it a try for a few days without DOM navigation.
Inevitably, if you're not used to it, it's going to take some getting
used to, however if you're anything like me, I feel that eventually, you
will really start to see the benefits of not using DOM. DOM is great in
my opinion, don't get me wrong, but if you want, or need in a mission
critical environment to have an exact representation of the content,
then fact is fact, you're not going to get it with DOM mode, end of the
story, it's just not gonna happen, period. You might as well just accept
it. The other thing to also realize is, you are taking up unnecessary
memory/processor power to render things differently as an offline model.
Granted, OK, it may not be much, but that's not the point. It's still
taking up what to some would be considered as unnecessary
resources.
What are your thoughts?
Do you use DOM? If not, I'd be interested in your reasons why
not.
Chris.
