No TABLES in html. No hacks in CSS. Any layout possible,crossbrowser. Try it.

Ben C wrote:

On 2008-01-03, Bergamot <bergamot (AT) visi (DOT) com> wrote:

Anybody tried this thing with JAWS or some other screen reader?

The idea is that the screen reader would read out the uncluttered HTML,
not the generated table soup.

I don't think it's that simple. All the major Windows screen readers use
IE's rendering engine for web browsing. I presume they'll only "look" at
the HTML if JavaScript is disabled.

I don't know if that actually works.

It seems unlikely, to me anyway.

--
Berg

On Jan 3, 4:36 pm, Bergamot <berga... (AT) visi (DOT) com> wrote:

Ben C wrote:
On 2008-01-03, Bergamot <berga... (AT) visi (DOT) com> wrote:

Anybody tried this thing with JAWS or some other screen reader?

The idea is that the screen reader would read out the uncluttered HTML,
not the generated table soup.

I don't think it's that simple. All the major Windows screen readers use
IE's rendering engine for web browsing. I presume they'll only "look" at
the HTML if JavaScript is disabled.

I don't know if that actually works.

It seems unlikely, to me anyway.

Could somebody test this please?

On Jan 3, 4:36 pm, Bergamot <berga... (AT) visi (DOT) com> wrote:

Ben C wrote:
On 2008-01-03, Bergamot <berga... (AT) visi (DOT) com> wrote:

Anybody tried this thing with JAWS or some other screen reader?

The idea is that the screen reader would read out the uncluttered HTML,
not the generated table soup.

I don't think it's that simple. All the major Windows screen readers use
IE's rendering engine for web browsing. I presume they'll only "look" at
the HTML if JavaScript is disabled.

I've checked how jaws actually behaves.

It reads whatever is seen on the screen line by line. It does not read
HTML source. It does not read DOM tree. It seems like it reads actual
pixels visible on the screen.
So as far as I can figure out any layout that has more than one column
is not JAWS friendly because it reads one line from left column and
immediately, without stopping reads line from center column. And then
it reads second line from left column and immediately second line from
center column. I tested it with pages using my lib and pages from
zengarden. They behave exactly the same. I guess any person who uses
JAWS must probably disable javascript and css on all pages to avoid
multiple columns. In such case my layout and pure css layouts behave
exactly the same.

brave1979 wrote:

I've checked how jaws actually behaves.

It reads whatever is seen on the screen line by line. It does not read
HTML source. It does not read DOM tree.

Have you verified that there aren't configuration options that do it
differently?

BTW, you do know that JAWS isn't the only reader, eh? It is probably the
most used one, though.

--
Berg

On Jan 6, 11:36 pm, Bergamot <berga... (AT) visi (DOT) com> wrote:

brave1979 wrote:

I've checked how jaws actually behaves.

It reads whatever is seen on the screen line by line. It does not read
HTML source. It does not read DOM tree.

Have you verified that there aren't configuration options that do it
differently?
This program is not exactly user friendly, so I am far from claiming

that I exhausted all option available.

BTW, you do know that JAWS isn't the only reader, eh? It is probably the
most used one, though.
It makes sense that it tries to read actual pixels on the screen.

Hence the name "screen reader". Probably other screen readers do
something similar.

I think BraveLayout is quite safe to use, regarding people with
disabilities.

Sorry to see so many posts being overly critical, it seems like people
are complaining against tables even when there are none in the html!
One of the main reasons to not have tables is because it clutters up
the code, it does not matter if your output has tables that no one
sees, that is ridiculous for people to complain about... seems like
they are just trying to be rude.

You put hard work into a different layout solution which I think is
wonderful.
Of course there are a few concerns people have addressed but currently
I think it's pretty solid. I want to thank you, your bravelayout is
definately a step in the right direction.

On 14 Jan, 20:23, Chemixst <matthay... (AT) gmail (DOT) com> wrote:

Sorry to see so many posts being overly critical, it seems like people
are complaining against tables even when there are none in the html!
One of the main reasons to not have tables is because it clutters up
the code, it does not matter if your output has tables that no one
sees, that is ridiculous for people to complain about... seems like
they are just trying to be rude.

Oh, don't talk shite.

Chemixst wrote:

Sorry to see so many posts being overly critical, it seems like people
are complaining against tables even when there are none in the html!
One of the main reasons to not have tables is because it clutters up
the code, it does not matter if your output has tables that no one
sees, that is ridiculous for people to complain about... seems like
they are just trying to be rude.

You put hard work into a different layout solution which I think is
wonderful.
Of course there are a few concerns people have addressed but currently
I think it's pretty solid. I want to thank you, your bravelayout is
definately a step in the right direction.

No the problem as I recall was that the "method" relied on client side
JavaScript to produce the page. In the 90's when DHTML was the buzz word
and security wasn't considered this "bird" may have flown. Requiring
JavaScript for your site to function is a bad idea today on too many
ways to list. Google if you want more info...

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com