|
Christopher-Mark Gilland <clgilland07@...>
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.
|
|
|
Hello,
I an not using screen layout like in your second example due to following reasons: - By navigating with down arrow link by link I can decide by myself how fast things are being red since I can decide not to hear the whole link label, but only let‘s say the first half of the word. I don‘t have to wait until the last link on the tab is being announced - If I want to navigate link by link in screen layout, then I have to press the ctrl key and the right arrow key (applies only for link bars like you have described or for forms with many elements on one line). The problem is that pressing ctrl + right arrow NVDA reads word by word and not link by link or button by button. So I am navigating much slower through the content - When navigating by ctrl + right arrow through a link bar with 5 links to focus the last one, I don‘t know when the bar ends unless I have listened to NVDA reading the whole bar before - There is the NVDA addon audiotheme 3d which gives me a screen presentation by playing a short sound in my headfones exactly at the position where the object is located on the screen.
Best Adriani Von meinem iPhone gesendet
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.
|
|
|
Christopher-Mark Gilland <clgilland07@...>
Adriani,
You make some extremely valid points which should
be carefully considered, yes. Thanks for your contribution to the thread, and
fair enough statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58
AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to following
reasons:
- By navigating with down arrow link by link I can decide by myself how
fast things are being red since I can decide not to hear the whole link label,
but only let‘s say the first half of the word. I don‘t have to wait until the
last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have to
press the ctrl key and the right arrow key (applies only for link bars like
you have described or for forms with many elements on one line). The problem
is that pressing ctrl + right arrow NVDA reads word by word and not link by
link or button by button. So I am navigating much slower through the
content
- When navigating by ctrl + right arrow through a link bar with 5 links
to focus the last one, I don‘t know when the bar ends unless I have listened
to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the position
where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
|
|
|
Brian's Mail list account
How does it save memory not doing so. The point is in nvda an off screen model is built either way and you have the choice of links etc on one line or not, You also have single key navigation which in your example should work the same either way if you are looking for say edit fields in a form or links to things. The point is that if I were designing a web page for us, as you say the contact us link would be to a sub index also containing the link to the form. I'd also not disable going back as some sites do as in this case unless you are using tabs for pages getting back if you do key a wrong link is not easy to do.
Do I want things to sound like they look?
Well that very much depends on the design. So many forms use tabular organisation then come out and use other ways to put the content of description fields for edit boxes. If I could always force edit boxes to be under their descriptors I'd jump at the chance as otherwise I'd never know which checkbox or whatever went with which choice would I?
So really, I find that often although its good to have a visual image so to speak of what was going on on a site, often you need to think of a web page differently for accessing its silly.
Also those blind from the word go, will no doubt have their own way to mentally arrange things completely different to the sighted. This is why I also get very annoyed at pages where any list of links or whatever are not logical. It may look logical but whoever designed it did not take that logic to the order we would encounter using single key navigation. It can take an age cursoring around a page in the sighted way to find the true layout, and who can remember such a trip in detail? One has to make it simple. Many web designers need to realise the problem of us having no overview as the sighted do when they design pages. I'd much prefer less cluttered pages and have a simple theme and a hierarchical set up where its like a book with indexing myself.
Brian
bglists@...
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
toggle quoted message
Show quoted text
----- Original Message -----
From: "Christopher-Mark Gilland" <clgilland07@...>
To: <nvda@nvda.groups.io>
Sent: Friday, December 01, 2017 8:20 AM
Subject: [nvda] The DOM Debate
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:
a.. Home
b.. About Us
c.. Blog
d.. Shop
e.. Support
f.. 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.
|
|
|
If you know how web pages are actually organized,
the contacts problem and other such possible problems can be eliminated very
easily. We, blind people, see a lot of links moving down from the
top of the page. A sighted person sees these running down the left side of
the page in a column. Then we see the main content below the links. A
sighted person sees the content toward the middle of the page, moving from left
to right on the page. Then a blind user sees a lot of links in a block at
the bottom of the page. A sighted person sees these links running down the
right side of the page in another column, in the same way as the links on the
left side are seen.
So a blind person sees a bloc of links at the top,
main content below the links then another block of links at the bottom. A
sighted person sees links running down the left side, main content to the right
of those links, and on the right another block of links running down the page in
a column.
So, if you are using a screen-reader with the
ridiculous word wrap feature, turn it off if it isn't off. then do a
screen-reader search for the word contact from the top of the page. Repeat
the search to see how many contact links there are. The one a sighted
person describes as being on the right is the one the blind person will see as
the second one, if there are only two and no more and there shouldn't be any
more. If there is only one, there is, of course, no problem. When
you get to the last one, if you repeat the search again, you will get an
error message. If you dismiss the error message, you will still be on the
link. You won't lose your place.
You don't have to give up all the advantages of
reorganization and usually it is much better to leave reorganization
on.
Gene
toggle quoted message
Show quoted text
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should
be carefully considered, yes. Thanks for your contribution to the thread, and
fair enough statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58
AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to following
reasons:
- By navigating with down arrow link by link I can decide by myself how
fast things are being red since I can decide not to hear the whole link label,
but only let‘s say the first half of the word. I don‘t have to wait until the
last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have to
press the ctrl key and the right arrow key (applies only for link bars like
you have described or for forms with many elements on one line). The problem
is that pressing ctrl + right arrow NVDA reads word by word and not link by
link or button by button. So I am navigating much slower through the
content
- When navigating by ctrl + right arrow through a link bar with 5 links
to focus the last one, I don‘t know when the bar ends unless I have listened
to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the position
where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
|
|
|
Hi Gene,
Long story short of your analysis: learn to use your screen
reader's quick navigation keys and other features. This allows
the reorganization and the advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the
contacts problem and other such possible problems can be
eliminated very easily. We, blind people, see a lot of links
moving down from the top of the page. A sighted person sees
these running down the left side of the page in a column. Then
we see the main content below the links. A sighted person sees
the content toward the middle of the page, moving from left to
right on the page. Then a blind user sees a lot of links in a
block at the bottom of the page. A sighted person sees these
links running down the right side of the page in another column,
in the same way as the links on the left side are seen.
So a blind person sees a bloc of links at the top, main
content below the links then another block of links at the
bottom. A sighted person sees links running down the left side,
main content to the right of those links, and on the right
another block of links running down the page in a column.
So, if you are using a screen-reader with the ridiculous word
wrap feature, turn it off if it isn't off. then do a
screen-reader search for the word contact from the top of the
page. Repeat the search to see how many contact links there
are. The one a sighted person describes as being on the right
is the one the blind person will see as the second one, if there
are only two and no more and there shouldn't be any more. If
there is only one, there is, of course, no problem. When you
get to the last one, if you repeat the search again, you will
get an error message. If you dismiss the error message, you
will still be on the link. You won't lose your place.
You don't have to give up all the advantages of
reorganization and usually it is much better to leave
reorganization on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be
carefully considered, yes. Thanks for your contribution to the
thread, and fair enough statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58 AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example
due to following reasons:
- By navigating with down arrow link by link I can decide
by myself how fast things are being red since I can decide not
to hear the whole link label, but only let‘s say the first
half of the word. I don‘t have to wait until the last link on
the tab is being announced
- If I want to navigate link by link in screen layout, then
I have to press the ctrl key and the right arrow key (applies
only for link bars like you have described or for forms with
many elements on one line). The problem is that pressing ctrl
+ right arrow NVDA reads word by word and not link by link or
button by button. So I am navigating much slower through the
content
- When navigating by ctrl + right arrow through a link bar
with 5 links to focus the last one, I don‘t know when the bar
ends unless I have listened to NVDA reading the whole bar
before
- There is the NVDA addon audiotheme 3d which gives me a
screen presentation by playing a short sound in my headfones
exactly at the position where the object is located on the
screen.
Best
Adriani
Von meinem iPhone gesendet
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.
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
Certainly, for those who want to use programs that
are not completely accessible, and that includes most somewhat demanding and
more demanding users, those are important things to learn. But in this
case, I think my analysis points to a much deeper problem, the poor Internet
instruction a lot of blind people evidently get. I wonder how much traning
material explains things such as I describe. I don't know but I'm
skeptical that it is explained in a lot of material because of the kinds of
problems and questions people raise about using the Internet.
Gene
toggle quoted message
Show quoted text
----- Original Message -----
Sent: Friday, December 01, 2017 9:42 AM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
Long story short of your analysis: learn to use your screen reader's quick
navigation keys and other features. This allows the reorganization and the
advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the contacts problem
and other such possible problems can be eliminated very easily. We,
blind people, see a lot of links moving down from the top of the
page. A sighted person sees these running down the left side of the page
in a column. Then we see the main content below the links. A sighted
person sees the content toward the middle of the page, moving from left to
right on the page. Then a blind user sees a lot of links in a block at
the bottom of the page. A sighted person sees these links running down
the right side of the page in another column, in the same way as the links on
the left side are seen.
So a blind person sees a bloc of links at the top, main content below the
links then another block of links at the bottom. A sighted person sees
links running down the left side, main content to the right of those links,
and on the right another block of links running down the page in a
column.
So, if you are using a screen-reader with the ridiculous word wrap
feature, turn it off if it isn't off. then do a screen-reader search for
the word contact from the top of the page. Repeat the search to see how
many contact links there are. The one a sighted person describes as
being on the right is the one the blind person will see as the second one, if
there are only two and no more and there shouldn't be any more. If there
is only one, there is, of course, no problem. When you get to the last
one, if you repeat the search again, you will get an error message.
If you dismiss the error message, you will still be on the link. You
won't lose your place.
You don't have to give up all the advantages of reorganization and
usually it is much better to leave reorganization on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be carefully
considered, yes. Thanks for your contribution to the thread, and fair enough
statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58 AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by myself how
fast things are being red since I can decide not to hear the whole link
label, but only let‘s say the first half of the word. I don‘t have to wait
until the last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have to
press the ctrl key and the right arrow key (applies only for link bars like
you have described or for forms with many elements on one line). The problem
is that pressing ctrl + right arrow NVDA reads word by word and not link by
link or button by button. So I am navigating much slower through the
content
- When navigating by ctrl + right arrow through a link bar with 5 links
to focus the last one, I don‘t know when the bar ends unless I have listened
to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the
position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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. --
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
Christopher-Mark Gilland <clgilland07@...>
Gene, the problem is, the way you describe the
layout of a page certainly might make sense, and it may even be mostly standard,
but there are those exceptions, trust me.
Enough said.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 6:44
AM
Subject: Re: [nvda] The DOM Debate
If you know how web pages are actually organized,
the contacts problem and other such possible problems can be eliminated very
easily. We, blind people, see a lot of links moving down from the
top of the page. A sighted person sees these running down the left side
of the page in a column. Then we see the main content below the
links. A sighted person sees the content toward the middle of the page,
moving from left to right on the page. Then a blind user sees a lot of
links in a block at the bottom of the page. A sighted person sees these
links running down the right side of the page in another column, in the same
way as the links on the left side are seen.
So a blind person sees a bloc of links at the
top, main content below the links then another block of links at the
bottom. A sighted person sees links running down the left side, main
content to the right of those links, and on the right another block of links
running down the page in a column.
So, if you are using a screen-reader with the
ridiculous word wrap feature, turn it off if it isn't off. then do a
screen-reader search for the word contact from the top of the page.
Repeat the search to see how many contact links there are. The one a
sighted person describes as being on the right is the one the blind person
will see as the second one, if there are only two and no more and there
shouldn't be any more. If there is only one, there is, of course, no
problem. When you get to the last one, if you repeat the search
again, you will get an error message. If you dismiss the error message,
you will still be on the link. You won't lose your place.
You don't have to give up all the advantages of
reorganization and usually it is much better to leave reorganization
on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should
be carefully considered, yes. Thanks for your contribution to the thread, and
fair enough statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58
AM
Subject: Re: [nvda] The DOM
Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by myself how
fast things are being red since I can decide not to hear the whole link
label, but only let‘s say the first half of the word. I don‘t have to wait
until the last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have to
press the ctrl key and the right arrow key (applies only for link bars like
you have described or for forms with many elements on one line). The problem
is that pressing ctrl + right arrow NVDA reads word by word and not link by
link or button by button. So I am navigating much slower through the
content
- When navigating by ctrl + right arrow through a link bar with 5 links
to focus the last one, I don‘t know when the bar ends unless I have listened
to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the
position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
|
|
|
Christopher-Mark Gilland <clgilland07@...>
I absolutely know how to use quick navigation. I've
been doing this since the first implementation of the concept back in, what
would that have been, JAWS 4? Then of corse the concept carried over into NVDA,
as well as other screen readers.
I'm not dismissing what you're saying, as much as
I'm simply saying that these navigation keystrokes only give you about 85% of
the screen layout. It's certainly very close, don't get me wrong, but there may
be times you need to dive deeper.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 10:42
AM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
Long story short of your analysis: learn to use your screen reader's quick
navigation keys and other features. This allows the reorganization and
the advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the contacts problem
and other such possible problems can be eliminated very easily. We,
blind people, see a lot of links moving down from the top of the
page. A sighted person sees these running down the left side of the
page in a column. Then we see the main content below the links. A
sighted person sees the content toward the middle of the page, moving from
left to right on the page. Then a blind user sees a lot of links in a
block at the bottom of the page. A sighted person sees these links
running down the right side of the page in another column, in the same way
as the links on the left side are seen.
So a blind person sees a bloc of links at the top, main content below
the links then another block of links at the bottom. A sighted person
sees links running down the left side, main content to the right of those
links, and on the right another block of links running down the page in a
column.
So, if you are using a screen-reader with the ridiculous word wrap
feature, turn it off if it isn't off. then do a screen-reader search
for the word contact from the top of the page. Repeat the search to
see how many contact links there are. The one a sighted person
describes as being on the right is the one the blind person will see as the
second one, if there are only two and no more and there shouldn't be any
more. If there is only one, there is, of course, no problem.
When you get to the last one, if you repeat the search again, you will
get an error message. If you dismiss the error message, you will still
be on the link. You won't lose your place.
You don't have to give up all the advantages of reorganization and
usually it is much better to leave reorganization on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be carefully
considered, yes. Thanks for your contribution to the thread, and fair enough
statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58 AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by myself
how fast things are being red since I can decide not to hear the whole
link label, but only let‘s say the first half of the word. I don‘t have to
wait until the last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have to
press the ctrl key and the right arrow key (applies only for link bars
like you have described or for forms with many elements on one line). The
problem is that pressing ctrl + right arrow NVDA reads word by word and
not link by link or button by button. So I am navigating much slower
through the content
- When navigating by ctrl + right arrow through a link bar with 5
links to focus the last one, I don‘t know when the bar ends unless I have
listened to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the
position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
I can't comment on that because you provide no
description or examples, nor any explanation of how seeing the page not
reorganized would help deal with the exceptions. You are saying that my
explanation isn't complete because of exceptions but you give no way to evaluate
your contention.
Gene
toggle quoted message
Show quoted text
----- Original Message -----
Sent: Friday, December 01, 2017 10:09 AM
Subject: Re: [nvda] The DOM Debate
Gene, the problem is, the way you describe the
layout of a page certainly might make sense, and it may even be mostly standard,
but there are those exceptions, trust me.
Enough said.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 6:44
AM
Subject: Re: [nvda] The DOM Debate
If you know how web pages are actually organized,
the contacts problem and other such possible problems can be eliminated very
easily. We, blind people, see a lot of links moving down from the
top of the page. A sighted person sees these running down the left side
of the page in a column. Then we see the main content below the
links. A sighted person sees the content toward the middle of the page,
moving from left to right on the page. Then a blind user sees a lot of
links in a block at the bottom of the page. A sighted person sees these
links running down the right side of the page in another column, in the same
way as the links on the left side are seen.
So a blind person sees a bloc of links at the
top, main content below the links then another block of links at the
bottom. A sighted person sees links running down the left side, main
content to the right of those links, and on the right another block of links
running down the page in a column.
So, if you are using a screen-reader with the
ridiculous word wrap feature, turn it off if it isn't off. then do a
screen-reader search for the word contact from the top of the page.
Repeat the search to see how many contact links there are. The one a
sighted person describes as being on the right is the one the blind person
will see as the second one, if there are only two and no more and there
shouldn't be any more. If there is only one, there is, of course, no
problem. When you get to the last one, if you repeat the search
again, you will get an error message. If you dismiss the error message,
you will still be on the link. You won't lose your place.
You don't have to give up all the advantages of
reorganization and usually it is much better to leave reorganization
on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should
be carefully considered, yes. Thanks for your contribution to the thread, and
fair enough statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58
AM
Subject: Re: [nvda] The DOM
Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by myself how
fast things are being red since I can decide not to hear the whole link
label, but only let‘s say the first half of the word. I don‘t have to wait
until the last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have to
press the ctrl key and the right arrow key (applies only for link bars like
you have described or for forms with many elements on one line). The problem
is that pressing ctrl + right arrow NVDA reads word by word and not link by
link or button by button. So I am navigating much slower through the
content
- When navigating by ctrl + right arrow through a link bar with 5 links
to focus the last one, I don‘t know when the bar ends unless I have listened
to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the
position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
|
|
|
Brian's Mail list account
In a way I'm in a good place cos I saw web pages before I lost all my sight. However it should not really matter as long as the site does not say stuff like click the blue triangle near the top right corner for the information, and then assign a tag for said triangle as some cryptic link identifier instead of blue triangle 1 or whatever.
Half the problems I get from people is that they have been told about web layout but it means nothing whatsoever in a world where there is just up and down most of the time and stuff on the right is blow stuff on the left.
Brian
bglists@...
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
toggle quoted message
Show quoted text
----- Original Message ----- From: "Gene" <gsasner@...> To: <nvda@nvda.groups.io> Sent: Friday, December 01, 2017 4:07 PM Subject: Re: [nvda] The DOM Debate Certainly, for those who want to use programs that are not completely accessible, and that includes most somewhat demanding and more demanding users, those are important things to learn. But in this case, I think my analysis points to a much deeper problem, the poor Internet instruction a lot of blind people evidently get. I wonder how much traning material explains things such as I describe. I don't know but I'm skeptical that it is explained in a lot of material because of the kinds of problems and questions people raise about using the Internet. Gene ----- Original Message ----- From: Ron Canazzi Sent: Friday, December 01, 2017 9:42 AM To: nvda@nvda.groups.io Subject: Re: [nvda] The DOM Debate Hi Gene, Long story short of your analysis: learn to use your screen reader's quick navigation keys and other features. This allows the reorganization and the advantages of DOM to coexist. On 12/1/2017 6:44 AM, Gene wrote: If you know how web pages are actually organized, the contacts problem and other such possible problems can be eliminated very easily. We, blind people, see a lot of links moving down from the top of the page. A sighted person sees these running down the left side of the page in a column. Then we see the main content below the links. A sighted person sees the content toward the middle of the page, moving from left to right on the page. Then a blind user sees a lot of links in a block at the bottom of the page. A sighted person sees these links running down the right side of the page in another column, in the same way as the links on the left side are seen. So a blind person sees a bloc of links at the top, main content below the links then another block of links at the bottom. A sighted person sees links running down the left side, main content to the right of those links, and on the right another block of links running down the page in a column. So, if you are using a screen-reader with the ridiculous word wrap feature, turn it off if it isn't off. then do a screen-reader search for the word contact from the top of the page. Repeat the search to see how many contact links there are. The one a sighted person describes as being on the right is the one the blind person will see as the second one, if there are only two and no more and there shouldn't be any more. If there is only one, there is, of course, no problem. When you get to the last one, if you repeat the search again, you will get an error message. If you dismiss the error message, you will still be on the link. You won't lose your place. You don't have to give up all the advantages of reorganization and usually it is much better to leave reorganization on. Gene ----- Original Message ----- From: Christopher-Mark Gilland Sent: Friday, December 01, 2017 3:08 AM To: nvda@nvda.groups.io Subject: Re: [nvda] The DOM Debate Adriani, You make some extremely valid points which should be carefully considered, yes. Thanks for your contribution to the thread, and fair enough statements. --- Christopher Gilland Co-founder of Genuine Safe Haven Ministries http://www.gshministry.org (980) 500-9575 ----- Original Message ----- From: Adriani Botez To: nvda@nvda.groups.io Sent: Friday, December 01, 2017 3:58 AM Subject: Re: [nvda] The DOM Debate Hello, I an not using screen layout like in your second example due to following reasons: - By navigating with down arrow link by link I can decide by myself how fast things are being red since I can decide not to hear the whole link label, but only let‘s say the first half of the word. I don‘t have to wait until the last link on the tab is being announced - If I want to navigate link by link in screen layout, then I have to press the ctrl key and the right arrow key (applies only for link bars like you have described or for forms with many elements on one line). The problem is that pressing ctrl + right arrow NVDA reads word by word and not link by link or button by button. So I am navigating much slower through the content - When navigating by ctrl + right arrow through a link bar with 5 links to focus the last one, I don‘t know when the bar ends unless I have listened to NVDA reading the whole bar before - There is the NVDA addon audiotheme 3d which gives me a screen presentation by playing a short sound in my headfones exactly at the position where the object is located on the screen. Best Adriani Von meinem iPhone gesendet Am 01.12.2017 um 09:20 schrieb Christopher-Mark Gilland <clgilland07@...>: 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: a.. Home b.. About Us c.. Blog d.. Shop e.. Support f.. 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. -- They Ask Me If I'm Happy; I say Yes. They ask: "How Happy are You?" I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
Brian's Mail list account
It gets very vcomplex with landmarks frames and whatever Yahoo are up to which seems to be mostly chaos....
Brian
bglists@...
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
toggle quoted message
Show quoted text
----- Original Message ----- From: "Christopher-Mark Gilland" <clgilland07@...> To: <nvda@nvda.groups.io> Sent: Friday, December 01, 2017 4:09 PM Subject: Re: [nvda] The DOM Debate Gene, the problem is, the way you describe the layout of a page certainly might make sense, and it may even be mostly standard, but there are those exceptions, trust me. Enough said. --- Christopher Gilland Co-founder of Genuine Safe Haven Ministries http://www.gshministry.org(980) 500-9575 ----- Original Message ----- From: Gene To: nvda@nvda.groups.io Sent: Friday, December 01, 2017 6:44 AM Subject: Re: [nvda] The DOM Debate If you know how web pages are actually organized, the contacts problem and other such possible problems can be eliminated very easily. We, blind people, see a lot of links moving down from the top of the page. A sighted person sees these running down the left side of the page in a column. Then we see the main content below the links. A sighted person sees the content toward the middle of the page, moving from left to right on the page. Then a blind user sees a lot of links in a block at the bottom of the page. A sighted person sees these links running down the right side of the page in another column, in the same way as the links on the left side are seen. So a blind person sees a bloc of links at the top, main content below the links then another block of links at the bottom. A sighted person sees links running down the left side, main content to the right of those links, and on the right another block of links running down the page in a column. So, if you are using a screen-reader with the ridiculous word wrap feature, turn it off if it isn't off. then do a screen-reader search for the word contact from the top of the page. Repeat the search to see how many contact links there are. The one a sighted person describes as being on the right is the one the blind person will see as the second one, if there are only two and no more and there shouldn't be any more. If there is only one, there is, of course, no problem. When you get to the last one, if you repeat the search again, you will get an error message. If you dismiss the error message, you will still be on the link. You won't lose your place. You don't have to give up all the advantages of reorganization and usually it is much better to leave reorganization on. Gene ----- Original Message ----- From: Christopher-Mark Gilland Sent: Friday, December 01, 2017 3:08 AM To: nvda@nvda.groups.io Subject: Re: [nvda] The DOM Debate Adriani, You make some extremely valid points which should be carefully considered, yes. Thanks for your contribution to the thread, and fair enough statements. --- Christopher Gilland Co-founder of Genuine Safe Haven Ministries http://www.gshministry.org (980) 500-9575 ----- Original Message ----- From: Adriani Botez To: nvda@nvda.groups.io Sent: Friday, December 01, 2017 3:58 AM Subject: Re: [nvda] The DOM Debate Hello, I an not using screen layout like in your second example due to following reasons: - By navigating with down arrow link by link I can decide by myself how fast things are being red since I can decide not to hear the whole link label, but only let‘s say the first half of the word. I don‘t have to wait until the last link on the tab is being announced - If I want to navigate link by link in screen layout, then I have to press the ctrl key and the right arrow key (applies only for link bars like you have described or for forms with many elements on one line). The problem is that pressing ctrl + right arrow NVDA reads word by word and not link by link or button by button. So I am navigating much slower through the content - When navigating by ctrl + right arrow through a link bar with 5 links to focus the last one, I don‘t know when the bar ends unless I have listened to NVDA reading the whole bar before - There is the NVDA addon audiotheme 3d which gives me a screen presentation by playing a short sound in my headfones exactly at the position where the object is located on the screen. Best Adriani Von meinem iPhone gesendet Am 01.12.2017 um 09:20 schrieb Christopher-Mark Gilland <clgilland07@...>: 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: a.. Home b.. About Us c.. Blog d.. Shop e.. Support f.. 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.
|
|
|
Hi Gene,
\
I have had bad experiences with TVI people. One of them when
asked if she knew the basics of teaching JAWS said: "No, but I and
my client will learn it together." That speaks volumes.
On 12/1/2017 11:07 AM, Gene wrote:
Certainly, for those who want to use programs that are not
completely accessible, and that includes most somewhat demanding
and more demanding users, those are important things to learn.
But in this case, I think my analysis points to a much deeper
problem, the poor Internet instruction a lot of blind people
evidently get. I wonder how much traning material explains
things such as I describe. I don't know but I'm skeptical that
it is explained in a lot of material because of the kinds of
problems and questions people raise about using the Internet.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 9:42 AM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
Long story short of your analysis: learn to use your screen
reader's quick navigation keys and other features. This allows
the reorganization and the advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the
contacts problem and other such possible problems can be
eliminated very easily. We, blind people, see a lot of links
moving down from the top of the page. A sighted person sees
these running down the left side of the page in a column. Then
we see the main content below the links. A sighted person sees
the content toward the middle of the page, moving from left to
right on the page. Then a blind user sees a lot of links in a
block at the bottom of the page. A sighted person sees these
links running down the right side of the page in another
column, in the same way as the links on the left side are
seen.
So a blind person sees a bloc of links at the top, main
content below the links then another block of links at the
bottom. A sighted person sees links running down the left
side, main content to the right of those links, and on the
right another block of links running down the page in a
column.
So, if you are using a screen-reader with the ridiculous
word wrap feature, turn it off if it isn't off. then do a
screen-reader search for the word contact from the top of the
page. Repeat the search to see how many contact links there
are. The one a sighted person describes as being on the right
is the one the blind person will see as the second one, if
there are only two and no more and there shouldn't be any
more. If there is only one, there is, of course, no problem.
When you get to the last one, if you repeat the search again,
you will get an error message. If you dismiss the error
message, you will still be on the link. You won't lose your
place.
You don't have to give up all the advantages of
reorganization and usually it is much better to leave
reorganization on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be
carefully considered, yes. Thanks for your contribution to
the thread, and fair enough statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58 AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example
due to following reasons:
- By navigating with down arrow link by link I can decide
by myself how fast things are being red since I can decide
not to hear the whole link label, but only let‘s say the
first half of the word. I don‘t have to wait until the last
link on the tab is being announced
- If I want to navigate link by link in screen layout,
then I have to press the ctrl key and the right arrow key
(applies only for link bars like you have described or for
forms with many elements on one line). The problem is that
pressing ctrl + right arrow NVDA reads word by word and not
link by link or button by button. So I am navigating much
slower through the content
- When navigating by ctrl + right arrow through a link
bar with 5 links to focus the last one, I don‘t know when
the bar ends unless I have listened to NVDA reading the
whole bar before
- There is the NVDA addon audiotheme 3d which gives me a
screen presentation by playing a short sound in my headfones
exactly at the position where the object is located on the
screen.
Best
Adriani
Von meinem iPhone gesendet
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.
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
Brian's Mail list account
I do not propose I am a teacher, but recently after a lot of visits from an Online today supposedly trained person from RNIB I found they had not even covered the basics of the web yet.
She is a smart cookie so something stinks in the world of so called trainers I feel. I'm sure he was a nice enough person but really, they should be encouraging people to play with it having got the basics, not saying as I gather he did, that is much too complicated for you now.
Blaugh!
I was no taught I picked it all up so would not consider myself a trainer, but sometimes I do wonder if these people got their qualifications from a corn flake packet.
Brian
bglists@...
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
toggle quoted message
Show quoted text
----- Original Message ----- From: "Ron Canazzi" <aa2vm@...> To: <nvda@nvda.groups.io> Sent: Friday, December 01, 2017 6:35 PM Subject: Re: [nvda] The DOM Debate Hi Gene,
\
I have had bad experiences with TVI people. One of them when asked if
she knew the basics of teaching JAWS said: "No, but I and my client will
learn it together." That speaks volumes.
On 12/1/2017 11:07 AM, Gene wrote:
Certainly, for those who want to use programs that are not completely
accessible, and that includes most somewhat demanding and more
demanding users, those are important things to learn. But in this
case, I think my analysis points to a much deeper problem, the poor
Internet instruction a lot of blind people evidently get. I wonder
how much traning material explains things such as I describe. I don't
know but I'm skeptical that it is explained in a lot of material
because of the kinds of problems and questions people raise about
using the Internet.
Gene
----- Original Message -----
*From:* Ron Canazzi <mailto:aa2vm@...>
*Sent:* Friday, December 01, 2017 9:42 AM
*To:* nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
*Subject:* Re: [nvda] The DOM Debate
Hi Gene,
Long story short of your analysis: learn to use your screen reader's
quick navigation keys and other features. This allows the
reorganization and the advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the contacts
problem and other such possible problems can be eliminated very
easily. We, blind people, see a lot of links moving down from the
top of the page. A sighted person sees these running down the left
side of the page in a column. Then we see the main content below the
links. A sighted person sees the content toward the middle of the
page, moving from left to right on the page. Then a blind user sees
a lot of links in a block at the bottom of the page. A sighted
person sees these links running down the right side of the page in
another column, in the same way as the links on the left side are seen.
So a blind person sees a bloc of links at the top, main content below
the links then another block of links at the bottom. A sighted
person sees links running down the left side, main content to the
right of those links, and on the right another block of links running
down the page in a column.
So, if you are using a screen-reader with the ridiculous word wrap
feature, turn it off if it isn't off. then do a screen-reader search
for the word contact from the top of the page. Repeat the search to
see how many contact links there are. The one a sighted person
describes as being on the right is the one the blind person will see
as the second one, if there are only two and no more and there
shouldn't be any more. If there is only one, there is, of course, no
problem. When you get to the last one, if you repeat the search
again, you will get an error message. If you dismiss the error
message, you will still be on the link. You won't lose your place.
You don't have to give up all the advantages of reorganization and
usually it is much better to leave reorganization on.
Gene
----- Original Message -----
*From:* Christopher-Mark Gilland <mailto:clgilland07@...>
*Sent:* Friday, December 01, 2017 3:08 AM
*To:* nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
*Subject:* Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be carefully
considered, yes. Thanks for your contribution to the thread, and fair
enough statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven Ministries
http://www.gshministry.org
(980) 500-9575
----- Original Message -----
*From:* Adriani Botez <mailto:adriani.botez@...>
*To:* nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
*Sent:* Friday, December 01, 2017 3:58 AM
*Subject:* Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by
myself how fast things are being red since I can decide not to
hear the whole link label, but only let‘s say the first half of
the word. I don‘t have to wait until the last link on the tab is
being announced
- If I want to navigate link by link in screen layout, then I
have to press the ctrl key and the right arrow key (applies only
for link bars like you have described or for forms with many
elements on one line). The problem is that pressing ctrl + right
arrow NVDA reads word by word and not link by link or button by
button. So I am navigating much slower through the content
- When navigating by ctrl + right arrow through a link bar with 5
links to focus the last one, I don‘t know when the bar ends
unless I have listened to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at
the position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
Am 01.12.2017 um 09:20 schrieb Christopher-Mark Gilland
<clgilland07@... <mailto:clgilland07@...>>:
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. --
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
There is, I believe, an NVDA add on to quickly toggle screen layout on and off. You bring up a good point here, though. So many blind people have the mindset that going up and down through links is the way to go. Nobody knows about quick navigation keys and the problem there, for me at least, is using them means I lose focus, especially on huge sites. Try using amazon, for instance. Hitting h will take me to a heading, then focus will jump above that heading and I need to hit h again to go to the very same heading. It gets repetitive quickly. Usually in those cases, hitting down arrow works a lot better and isn’t jumping your focus around all over the place. That’s just one example. But your explanation made 100% crystal clear sense to me and I will try more sites with screen layout on.
From: GeneSent: December 1, 2017 10:25 AM To: nvda@nvda.groups.ioSubject: Re: [nvda] The DOM Debate I can't comment on that because you provide no description or examples, nor any explanation of how seeing the page not reorganized would help deal with the exceptions. You are saying that my explanation isn't complete because of exceptions but you give no way to evaluate your contention. ----- Original Message ----- Sent: Friday, December 01, 2017 10:09 AM Subject: Re: [nvda] The DOM Debate Gene, the problem is, the way you describe the layout of a page certainly might make sense, and it may even be mostly standard, but there are those exceptions, trust me. ---
Christopher Gilland
Co-founder of Genuine Safe Haven Ministries ----- Original Message ----- Sent: Friday, December 01, 2017 6:44 AM Subject: Re: [nvda] The DOM Debate If you know how web pages are actually organized, the contacts problem and other such possible problems can be eliminated very easily. We, blind people, see a lot of links moving down from the top of the page. A sighted person sees these running down the left side of the page in a column. Then we see the main content below the links. A sighted person sees the content toward the middle of the page, moving from left to right on the page. Then a blind user sees a lot of links in a block at the bottom of the page. A sighted person sees these links running down the right side of the page in another column, in the same way as the links on the left side are seen. So a blind person sees a bloc of links at the top, main content below the links then another block of links at the bottom. A sighted person sees links running down the left side, main content to the right of those links, and on the right another block of links running down the page in a column. So, if you are using a screen-reader with the ridiculous word wrap feature, turn it off if it isn't off. then do a screen-reader search for the word contact from the top of the page. Repeat the search to see how many contact links there are. The one a sighted person describes as being on the right is the one the blind person will see as the second one, if there are only two and no more and there shouldn't be any more. If there is only one, there is, of course, no problem. When you get to the last one, if you repeat the search again, you will get an error message. If you dismiss the error message, you will still be on the link. You won't lose your place. You don't have to give up all the advantages of reorganization and usually it is much better to leave reorganization on. ----- Original Message ----- Sent: Friday, December 01, 2017 3:08 AM Subject: Re: [nvda] The DOM Debate You make some extremely valid points which should be carefully considered, yes. Thanks for your contribution to the thread, and fair enough statements. ---
Christopher Gilland
Co-founder of Genuine Safe Haven Ministries ----- Original Message ----- Sent: Friday, December 01, 2017 3:58 AM Subject: Re: [nvda] The DOM Debate Hello, I an not using screen layout like in your second example due to following reasons: - By navigating with down arrow link by link I can decide by myself how fast things are being red since I can decide not to hear the whole link label, but only let‘s say the first half of the word. I don‘t have to wait until the last link on the tab is being announced - If I want to navigate link by link in screen layout, then I have to press the ctrl key and the right arrow key (applies only for link bars like you have described or for forms with many elements on one line). The problem is that pressing ctrl + right arrow NVDA reads word by word and not link by link or button by button. So I am navigating much slower through the content - When navigating by ctrl + right arrow through a link bar with 5 links to focus the last one, I don‘t know when the bar ends unless I have listened to NVDA reading the whole bar before - There is the NVDA addon audiotheme 3d which gives me a screen presentation by playing a short sound in my headfones exactly at the position where the object is located on the screen. Von meinem iPhone gesendet 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 BeastOne 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. 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 example without DOMRead 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 DOMPlease fill out the following form so we may keep in touch. E-mail Edit, Submit: button, Clear form: Button. The differenceAs 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 youSo 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 lineRegardless 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.
|
|
|
And I wonder how much actual training material such
as tutorials explains this or does so to any extent. Unless things have
changed, and I havedn't seen much discussion in quite some time, even small
changes in a web site causes mass confusion because so many people aren't taught
to explore pages. Just changing the download link to a download button
caused a lot of confusion when Send Space made that change. I hardly
noticed it when it happened because I used the screen-reader search feature to
find the word "download." I found the control just as easily and quickly
either way. Actually, the button is faster and easier because now I just
type b once from the top of the page to find it. But to those who learn by
rote, even minute changes may lead to an inability to do something on a
site.
Gene
toggle quoted message
Show quoted text
----- Original Message -----
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 12:35 PM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
\
I have had bad experiences with TVI people. One of them when asked if
she knew the basics of teaching JAWS said: "No, but I and my client will learn
it together." That speaks volumes.
On 12/1/2017 11:07 AM, Gene wrote:
Certainly, for those who want to use programs that are not completely
accessible, and that includes most somewhat demanding and more demanding
users, those are important things to learn. But in this case, I think my
analysis points to a much deeper problem, the poor Internet instruction a lot
of blind people evidently get. I wonder how much traning material
explains things such as I describe. I don't know but I'm skeptical that
it is explained in a lot of material because of the kinds of problems and
questions people raise about using the Internet.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 9:42 AM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
Long story short of your analysis: learn to use your screen reader's quick
navigation keys and other features. This allows the reorganization and
the advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the contacts problem
and other such possible problems can be eliminated very easily. We,
blind people, see a lot of links moving down from the top of the
page. A sighted person sees these running down the left side of the
page in a column. Then we see the main content below the links. A
sighted person sees the content toward the middle of the page, moving from
left to right on the page. Then a blind user sees a lot of links in a
block at the bottom of the page. A sighted person sees these links
running down the right side of the page in another column, in the same way
as the links on the left side are seen.
So a blind person sees a bloc of links at the top, main content below
the links then another block of links at the bottom. A sighted person
sees links running down the left side, main content to the right of those
links, and on the right another block of links running down the page in a
column.
So, if you are using a screen-reader with the ridiculous word wrap
feature, turn it off if it isn't off. then do a screen-reader search
for the word contact from the top of the page. Repeat the search to
see how many contact links there are. The one a sighted person
describes as being on the right is the one the blind person will see as the
second one, if there are only two and no more and there shouldn't be any
more. If there is only one, there is, of course, no problem.
When you get to the last one, if you repeat the search again, you will
get an error message. If you dismiss the error message, you will still
be on the link. You won't lose your place.
You don't have to give up all the advantages of reorganization and
usually it is much better to leave reorganization on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be carefully
considered, yes. Thanks for your contribution to the thread, and fair enough
statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58 AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by myself
how fast things are being red since I can decide not to hear the whole
link label, but only let‘s say the first half of the word. I don‘t have to
wait until the last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have to
press the ctrl key and the right arrow key (applies only for link bars
like you have described or for forms with many elements on one line). The
problem is that pressing ctrl + right arrow NVDA reads word by word and
not link by link or button by button. So I am navigating much slower
through the content
- When navigating by ctrl + right arrow through a link bar with 5
links to focus the last one, I don‘t know when the bar ends unless I have
listened to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the
position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!" --
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
Mary Otten <motten53@...>
Hi Jean, I agree with you for the most part, except that until fairly recently, didn’t all the screen readers use the Dhom model? I used the Mac for several years, and they have a group model as well as dom, and dom was more efficient as far as I was concerned. the search feature has proven much less reliable for me now that I’ve moved up to windows 10. I can search for things I know are there and get a no items found. Next time on there I get something. Frustrating. I think these pages are just too damn on needlessly complicated. Sent from my iPhone
On Dec 1, 2017, at 12:19 PM, Gene < gsasner@...> wrote:
And I wonder how much actual training material such
as tutorials explains this or does so to any extent. Unless things have
changed, and I havedn't seen much discussion in quite some time, even small
changes in a web site causes mass confusion because so many people aren't taught
to explore pages. Just changing the download link to a download button
caused a lot of confusion when Send Space made that change. I hardly
noticed it when it happened because I used the screen-reader search feature to
find the word "download." I found the control just as easily and quickly
either way. Actually, the button is faster and easier because now I just
type b once from the top of the page to find it. But to those who learn by
rote, even minute changes may lead to an inability to do something on a
site.
Gene
----- Original Message -----
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 12:35 PM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
\
I have had bad experiences with TVI people. One of them when asked if
she knew the basics of teaching JAWS said: "No, but I and my client will learn
it together." That speaks volumes.
On 12/1/2017 11:07 AM, Gene wrote:
Certainly, for those who want to use programs that are not completely
accessible, and that includes most somewhat demanding and more demanding
users, those are important things to learn. But in this case, I think my
analysis points to a much deeper problem, the poor Internet instruction a lot
of blind people evidently get. I wonder how much traning material
explains things such as I describe. I don't know but I'm skeptical that
it is explained in a lot of material because of the kinds of problems and
questions people raise about using the Internet.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 9:42 AM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
Long story short of your analysis: learn to use your screen reader's quick
navigation keys and other features. This allows the reorganization and
the advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the contacts problem
and other such possible problems can be eliminated very easily. We,
blind people, see a lot of links moving down from the top of the
page. A sighted person sees these running down the left side of the
page in a column. Then we see the main content below the links. A
sighted person sees the content toward the middle of the page, moving from
left to right on the page. Then a blind user sees a lot of links in a
block at the bottom of the page. A sighted person sees these links
running down the right side of the page in another column, in the same way
as the links on the left side are seen.
So a blind person sees a bloc of links at the top, main content below
the links then another block of links at the bottom. A sighted person
sees links running down the left side, main content to the right of those
links, and on the right another block of links running down the page in a
column.
So, if you are using a screen-reader with the ridiculous word wrap
feature, turn it off if it isn't off. then do a screen-reader search
for the word contact from the top of the page. Repeat the search to
see how many contact links there are. The one a sighted person
describes as being on the right is the one the blind person will see as the
second one, if there are only two and no more and there shouldn't be any
more. If there is only one, there is, of course, no problem.
When you get to the last one, if you repeat the search again, you will
get an error message. If you dismiss the error message, you will still
be on the link. You won't lose your place.
You don't have to give up all the advantages of reorganization and
usually it is much better to leave reorganization on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be carefully
considered, yes. Thanks for your contribution to the thread, and fair enough
statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58 AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by myself
how fast things are being red since I can decide not to hear the whole
link label, but only let‘s say the first half of the word. I don‘t have to
wait until the last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have to
press the ctrl key and the right arrow key (applies only for link bars
like you have described or for forms with many elements on one line). The
problem is that pressing ctrl + right arrow NVDA reads word by word and
not link by link or button by button. So I am navigating much slower
through the content
- When navigating by ctrl + right arrow through a link bar with 5
links to focus the last one, I don‘t know when the bar ends unless I have
listened to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the
position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!" --
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
I didn't keep the message from the person who said
he/she, I'm sorry, I don't remember who sent it, said that he/she would look at
more sites with screen layout on.
I don't know why, but even when I turn screen
layout off, I don't see most sites laid out as I described. Or, what I
should say is, I haven't seen the few sites I've looked at laid out that
way. Of course, you may experiment and from comments I've seen, screen
layout is useful for things like Internet user forms where you want to see
information presented in this way. But my intent in describing site layout
wasn't to imply that screen layout should be on for a lot more sites nor
that there is an advantage on most sites. My reason was to point out how
understanding how sites are generally laid out can help you find things when
someone gives you spacial references and where there may be more than one link
that is different that says the same or close to the same thing. I have
never seen a site where two contact links lead to two different places.
I'm not saying it doesn't happen, but I question whether it happens more than
rarely or rather rarely. But if spacial concepts matter in finding
something faster, knowing the layout of a site may be useful at times such as
described in the first message. But most of the time, if someone gives me
spacial directions, I use the site as I always would, using headings, skipping
blocks of links and the find feature, or if necessary, just reading down some of
the page.
Gene
toggle quoted message
Show quoted text
----- Original Message -----
Sent: Friday, December 01, 2017 2:19 PM
Subject: Re: [nvda] The DOM Debate
And I wonder how much actual training material such
as tutorials explains this or does so to any extent. Unless things have
changed, and I havedn't seen much discussion in quite some time, even small
changes in a web site causes mass confusion because so many people aren't taught
to explore pages. Just changing the download link to a download button
caused a lot of confusion when Send Space made that change. I hardly
noticed it when it happened because I used the screen-reader search feature to
find the word "download." I found the control just as easily and quickly
either way. Actually, the button is faster and easier because now I just
type b once from the top of the page to find it. But to those who learn by
rote, even minute changes may lead to an inability to do something on a
site.
Gene
----- Original Message -----
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 12:35 PM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
\
I have had bad experiences with TVI people. One of them when asked if
she knew the basics of teaching JAWS said: "No, but I and my client will learn
it together." That speaks volumes.
On 12/1/2017 11:07 AM, Gene wrote:
Certainly, for those who want to use programs that are not completely
accessible, and that includes most somewhat demanding and more demanding
users, those are important things to learn. But in this case, I think my
analysis points to a much deeper problem, the poor Internet instruction a lot
of blind people evidently get. I wonder how much traning material
explains things such as I describe. I don't know but I'm skeptical that
it is explained in a lot of material because of the kinds of problems and
questions people raise about using the Internet.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 9:42 AM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
Long story short of your analysis: learn to use your screen reader's quick
navigation keys and other features. This allows the reorganization and
the advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the contacts problem
and other such possible problems can be eliminated very easily. We,
blind people, see a lot of links moving down from the top of the
page. A sighted person sees these running down the left side of the
page in a column. Then we see the main content below the links. A
sighted person sees the content toward the middle of the page, moving from
left to right on the page. Then a blind user sees a lot of links in a
block at the bottom of the page. A sighted person sees these links
running down the right side of the page in another column, in the same way
as the links on the left side are seen.
So a blind person sees a bloc of links at the top, main content below
the links then another block of links at the bottom. A sighted person
sees links running down the left side, main content to the right of those
links, and on the right another block of links running down the page in a
column.
So, if you are using a screen-reader with the ridiculous word wrap
feature, turn it off if it isn't off. then do a screen-reader search
for the word contact from the top of the page. Repeat the search to
see how many contact links there are. The one a sighted person
describes as being on the right is the one the blind person will see as the
second one, if there are only two and no more and there shouldn't be any
more. If there is only one, there is, of course, no problem.
When you get to the last one, if you repeat the search again, you will
get an error message. If you dismiss the error message, you will still
be on the link. You won't lose your place.
You don't have to give up all the advantages of reorganization and
usually it is much better to leave reorganization on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be carefully
considered, yes. Thanks for your contribution to the thread, and fair enough
statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58 AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by myself
how fast things are being red since I can decide not to hear the whole
link label, but only let‘s say the first half of the word. I don‘t have to
wait until the last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have to
press the ctrl key and the right arrow key (applies only for link bars
like you have described or for forms with many elements on one line). The
problem is that pressing ctrl + right arrow NVDA reads word by word and
not link by link or button by button. So I am navigating much slower
through the content
- When navigating by ctrl + right arrow through a link bar with 5
links to focus the last one, I don‘t know when the bar ends unless I have
listened to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the
position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!" --
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
Evidently, at least Firefox is moving away from
supplying screen-readers information using the DOM. I don't think Edge
uses it nearly as much as screen-readers have in the past either. Someone
who knows a lot more than I do may provide more information. But even so,
browsers will still show screen layout in the same way even if the DOM model is
used much less or perhaps not at all. The DOM model doesn't mandate that
the screen be shown in a certain way. That's formatting.
Gene
toggle quoted message
Show quoted text
----- Original Message -----
Sent: Friday, December 01, 2017 2:42 PM
Subject: Re: [nvda] The DOM Debate
Hi Jean, I agree with you for the most part, except that until
fairly recently, didn’t all the screen readers use the Dhom model? I used
the Mac for several years, and they have a group model as well as dom, and dom
was more efficient as far as I was concerned. the search feature has
proven much less reliable for me now that I’ve moved up to windows 10. I can
search for things I know are there and get a no items found. Next time on there
I get something. Frustrating. I think these pages are just too damn on
needlessly complicated.
Sent from my iPhone
And I wonder how much actual training material
such as tutorials explains this or does so to any extent. Unless things
have changed, and I havedn't seen much discussion in quite some time, even
small changes in a web site causes mass confusion because so many people
aren't taught to explore pages. Just changing the download link to a
download button caused a lot of confusion when Send Space made that
change. I hardly noticed it when it happened because I used the
screen-reader search feature to find the word "download." I found the
control just as easily and quickly either way. Actually, the button is
faster and easier because now I just type b once from the top of the page to
find it. But to those who learn by rote, even minute changes may lead to
an inability to do something on a site.
Gene
----- Original Message -----
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 12:35 PM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
\
I have had bad experiences with TVI people. One of them when asked if
she knew the basics of teaching JAWS said: "No, but I and my client will learn
it together." That speaks volumes.
On 12/1/2017 11:07 AM, Gene wrote:
Certainly, for those who want to use programs that are not completely
accessible, and that includes most somewhat demanding and more demanding
users, those are important things to learn. But in this case, I think
my analysis points to a much deeper problem, the poor Internet instruction a
lot of blind people evidently get. I wonder how much traning material
explains things such as I describe. I don't know but I'm skeptical
that it is explained in a lot of material because of the kinds of problems
and questions people raise about using the Internet.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 9:42 AM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
Long story short of your analysis: learn to use your screen reader's
quick navigation keys and other features. This allows the
reorganization and the advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the contacts
problem and other such possible problems can be eliminated very
easily. We, blind people, see a lot of links moving down from
the top of the page. A sighted person sees these running down the
left side of the page in a column. Then we see the main content below
the links. A sighted person sees the content toward the middle of the
page, moving from left to right on the page. Then a blind user sees
a lot of links in a block at the bottom of the page. A sighted
person sees these links running down the right side of the page in another
column, in the same way as the links on the left side are
seen.
So a blind person sees a bloc of links at the top, main content below
the links then another block of links at the bottom. A sighted
person sees links running down the left side, main content to the right of
those links, and on the right another block of links running down the page
in a column.
So, if you are using a screen-reader with the ridiculous word wrap
feature, turn it off if it isn't off. then do a screen-reader search
for the word contact from the top of the page. Repeat the search to
see how many contact links there are. The one a sighted person
describes as being on the right is the one the blind person will see as
the second one, if there are only two and no more and there shouldn't be
any more. If there is only one, there is, of course, no
problem. When you get to the last one, if you repeat the search
again, you will get an error message. If you dismiss the error
message, you will still be on the link. You won't lose your
place.
You don't have to give up all the advantages of reorganization and
usually it is much better to leave reorganization on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be carefully
considered, yes. Thanks for your contribution to the thread, and fair
enough statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58 AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by myself
how fast things are being red since I can decide not to hear the whole
link label, but only let‘s say the first half of the word. I don‘t have
to wait until the last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have
to press the ctrl key and the right arrow key (applies only for link
bars like you have described or for forms with many elements on one
line). The problem is that pressing ctrl + right arrow NVDA reads word
by word and not link by link or button by button. So I am navigating
much slower through the content
- When navigating by ctrl + right arrow through a link bar with 5
links to focus the last one, I don‘t know when the bar ends unless I
have listened to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the
position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!" --
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
Mary Otten <motten53@...>
Well it would sure help if they had standards for all these kinds of buttons and things, like tabs and they identify as links or submenus or whatever. And then the screen readers react differently. It makes things a whole lot more complicated. I don’t care what it looks like, as I almost never get sighted direction like what you described. But when you run across something as badly label and don’t know how to interact with it, that is a problem. And then there are the sites that work great with one browser, letting you do a form with ease, while the other screen reader is horrible and doesn’t read any labels on any edit field. I don’t know why that is, but it is crazy. The cognitive load is getting greater and greater. And I’m not getting any younger. Smile Sent from my iPhone
On Dec 1, 2017, at 12:55 PM, Gene < gsasner@...> wrote:
Evidently, at least Firefox is moving away from
supplying screen-readers information using the DOM. I don't think Edge
uses it nearly as much as screen-readers have in the past either. Someone
who knows a lot more than I do may provide more information. But even so,
browsers will still show screen layout in the same way even if the DOM model is
used much less or perhaps not at all. The DOM model doesn't mandate that
the screen be shown in a certain way. That's formatting.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 2:42 PM
Subject: Re: [nvda] The DOM Debate
Hi Jean, I agree with you for the most part, except that until
fairly recently, didn’t all the screen readers use the Dhom model? I used
the Mac for several years, and they have a group model as well as dom, and dom
was more efficient as far as I was concerned. the search feature has
proven much less reliable for me now that I’ve moved up to windows 10. I can
search for things I know are there and get a no items found. Next time on there
I get something. Frustrating. I think these pages are just too damn on
needlessly complicated.
Sent from my iPhone
And I wonder how much actual training material
such as tutorials explains this or does so to any extent. Unless things
have changed, and I havedn't seen much discussion in quite some time, even
small changes in a web site causes mass confusion because so many people
aren't taught to explore pages. Just changing the download link to a
download button caused a lot of confusion when Send Space made that
change. I hardly noticed it when it happened because I used the
screen-reader search feature to find the word "download." I found the
control just as easily and quickly either way. Actually, the button is
faster and easier because now I just type b once from the top of the page to
find it. But to those who learn by rote, even minute changes may lead to
an inability to do something on a site.
Gene
----- Original Message -----
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 12:35 PM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
\
I have had bad experiences with TVI people. One of them when asked if
she knew the basics of teaching JAWS said: "No, but I and my client will learn
it together." That speaks volumes.
On 12/1/2017 11:07 AM, Gene wrote:
Certainly, for those who want to use programs that are not completely
accessible, and that includes most somewhat demanding and more demanding
users, those are important things to learn. But in this case, I think
my analysis points to a much deeper problem, the poor Internet instruction a
lot of blind people evidently get. I wonder how much traning material
explains things such as I describe. I don't know but I'm skeptical
that it is explained in a lot of material because of the kinds of problems
and questions people raise about using the Internet.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 9:42 AM
Subject: Re: [nvda] The DOM Debate
Hi Gene,
Long story short of your analysis: learn to use your screen reader's
quick navigation keys and other features. This allows the
reorganization and the advantages of DOM to coexist.
On 12/1/2017 6:44 AM, Gene wrote:
If you know how web pages are actually organized, the contacts
problem and other such possible problems can be eliminated very
easily. We, blind people, see a lot of links moving down from
the top of the page. A sighted person sees these running down the
left side of the page in a column. Then we see the main content below
the links. A sighted person sees the content toward the middle of the
page, moving from left to right on the page. Then a blind user sees
a lot of links in a block at the bottom of the page. A sighted
person sees these links running down the right side of the page in another
column, in the same way as the links on the left side are
seen.
So a blind person sees a bloc of links at the top, main content below
the links then another block of links at the bottom. A sighted
person sees links running down the left side, main content to the right of
those links, and on the right another block of links running down the page
in a column.
So, if you are using a screen-reader with the ridiculous word wrap
feature, turn it off if it isn't off. then do a screen-reader search
for the word contact from the top of the page. Repeat the search to
see how many contact links there are. The one a sighted person
describes as being on the right is the one the blind person will see as
the second one, if there are only two and no more and there shouldn't be
any more. If there is only one, there is, of course, no
problem. When you get to the last one, if you repeat the search
again, you will get an error message. If you dismiss the error
message, you will still be on the link. You won't lose your
place.
You don't have to give up all the advantages of reorganization and
usually it is much better to leave reorganization on.
Gene
----- Original Message -----
Sent: Friday, December 01, 2017 3:08 AM
Subject: Re: [nvda] The DOM Debate
Adriani,
You make some extremely valid points which should be carefully
considered, yes. Thanks for your contribution to the thread, and fair
enough statements.
---
Christopher Gilland
Co-founder of Genuine Safe Haven
Ministries
----- Original Message -----
Sent: Friday, December 01, 2017 3:58 AM
Subject: Re: [nvda] The DOM Debate
Hello,
I an not using screen layout like in your second example due to
following reasons:
- By navigating with down arrow link by link I can decide by myself
how fast things are being red since I can decide not to hear the whole
link label, but only let‘s say the first half of the word. I don‘t have
to wait until the last link on the tab is being announced
- If I want to navigate link by link in screen layout, then I have
to press the ctrl key and the right arrow key (applies only for link
bars like you have described or for forms with many elements on one
line). The problem is that pressing ctrl + right arrow NVDA reads word
by word and not link by link or button by button. So I am navigating
much slower through the content
- When navigating by ctrl + right arrow through a link bar with 5
links to focus the last one, I don‘t know when the bar ends unless I
have listened to NVDA reading the whole bar before
- There is the NVDA addon audiotheme 3d which gives me a screen
presentation by playing a short sound in my headfones exactly at the
position where the object is located on the screen.
Best
Adriani
Von meinem iPhone gesendet
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.
--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!" --
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"
|
|
|
