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.
