[Pro] Order of Items and CSS Menu trouble

I’m trying to arrange items so they’ll be read in the correct order with a screen reader. When I get the top CSS menu in the order I want it, its drop-down goes behind other elements. If I move it to front to fix that, it moves to the bottom of the Item’s list and is in the wrong order for the screen reader. If I drag it back to the top to put it in the right order, the drop-down goes behind the other elements. I’m in a loop. The menu is from a Master page. I arranged the order of the master page first but as soon as I add content to the child page I have to change the order. This is extremely frustrating, not to mention time consuming.

Any help? Please.

Thank you.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Sometime around 21/6/09 (at 22:15 -0400) wurliuchi said:

If I move it to front to fix that, it moves to the bottom of the
Item’s list and is in the wrong order for the screen reader. If I
drag it back to the top to put it in the right order, the drop-down
goes behind the other elements.

This is simply how these things work. The running order of the code
is determined by the stacking order in Freeway. Normally this is a
very nice and simple thing, and it fits 99.999% of all requirements.
But if you want to change the position of a particular div within the
code’s running order separately from the page layout object stacking
order you’re out of luck.

I suppose the CSS Menus action could be tweaked to set the div’s
z-order to something like 999 to put it above all others regardless
of where it sits in the stack. Perhaps a separate action could be
written to do that. Unfortunately, I’m not really an action writer so
I couldn’t help there.

k


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Thank you for the explanation. I don’t understand why moving an item to the front puts it on the bottom of the item stack. That and a lot of other things perplex the hell out of me.

It would be nice to have an “Always Keep In Front” check box in the CSS Menu Action.

Thanks again.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Sometime around 22/6/09 (at 05:11 -0400) wurliuchi said:

Thank you for the explanation. I don’t understand why moving an item
to the front puts it on the bottom of the item stack.

The list of items there is shown in ‘first/second/third’ order, just
as if you were writing items down in a list on paper. The first item
you write in your list is at the top of the page. The next item comes
below that, then the third item you add comes below the previous two,
etc.

Now look at the page rather than the list. When you add a new item to
your layout, it is always top-most in the stacking order. This is how
all DTP apps work, and how virtually every other kind of app (that
creates objects in a page-style space) works too.

Combine these two things and you get Freeway’s UI behaviour: the list
reflects the stacking order, which reflects the creation order. If
you shuffle things around in the page then the logical result is
things shuffled around in the list as well. (And you can use the list
order to rearrange the stacking order of items in the layout without
having to dig through piles of items in the page layout; just grab
and drag items up or down the list.)

Without this background info it can be a tad confusing. It could be
argued that the list should show new (top of the stack) items at the
top of the list. But there are arguments BOTH ways - and really, the
important thing is to understand the underlying logic of how things
work. :slight_smile:

It would be nice to have an “Always Keep In Front” check box in the
CSS Menu Action.

This is true. Of course, there is the issue of splitting the logic of
‘stacking order = output order’; if you JUST want it to be at the
top, bring it to the front. What you really want (if I’m
understanding things correctly) is for it to be at the front in
layout stacking terms but not in front of content divs in code
ordering terms, for accessibility reasons.

Perhaps just a minor terminology amendment might help? “Always Show
In Front” (Show rather than Keep)?

Anyway, this is purely idle conjecture as this feature doesn’t actually exist!

Also, it might be more useful in the short term as a free-standing
action that sets or alters the z-order of any chosen layered item
(div) rather than just the CSS Menus object. Certainly, I would have
thought it would be easier for some actions writer to put together!

k


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Thanks again, Keith. I just think it’s backwards. When you move an item to the back, it goes to the top of the list. When you move an item to the front, it goes to the bottom of the list. Admittedly I don’t know what I’m doing, but when I check it with Voiceover, whatever I have moved to the front is read last. It doesn’t make a whole lot of sense to me. Not that that’s going to change anything. I’ll just keep going and work it out the best I can. Making a site accessible is tough. I’m in over my head, but I’m stubborn.

On 22 Jun 2009, 9:53 am, thatkeith wrote:

Sometime around 22/6/09 (at 05:11 -0400) wurliuchi said:

Thank you for the explanation. I don’t understand why moving an item
to the front puts it on the bottom of the item stack.

The list of items there is shown in ‘first/second/third’ order, just
as if you were writing items down in a list on paper. The first item
you write in your list is at the top of the page. The next item comes
below that, then the third item you add comes below the previous two,
etc.

Now look at the page rather than the list. When you add a new item to
your layout, it is always top-most in the stacking order. This is how
all DTP apps work, and how virtually every other kind of app (that
creates objects in a page-style space) works too.

Combine these two things and you get Freeway’s UI behaviour: the list
reflects the stacking order, which reflects the creation order. If
you shuffle things around in the page then the logical result is
things shuffled around in the list as well. (And you can use the list
order to rearrange the stacking order of items in the layout without
having to dig through piles of items in the page layout; just grab
and drag items up or down the list.)

Without this background info it can be a tad confusing. It could be
argued that the list should show new (top of the stack) items at the
top of the list. But there are arguments BOTH ways - and really, the
important thing is to understand the underlying logic of how things
work. :slight_smile:

It would be nice to have an “Always Keep In Front” check box in the
CSS Menu Action.

This is true. Of course, there is the issue of splitting the logic of
‘stacking order = output order’; if you JUST want it to be at the
top, bring it to the front. What you really want (if I’m
understanding things correctly) is for it to be at the front in
layout stacking terms but not in front of content divs in code
ordering terms, for accessibility reasons.

Perhaps just a minor terminology amendment might help? “Always Show
In Front” (Show rather than Keep)?

Anyway, this is purely idle conjecture as this feature doesn’t actually exist!

Also, it might be more useful in the short term as a free-standing
action that sets or alters the z-order of any chosen layered item
(div) rather than just the CSS Menus object. Certainly, I would have
thought it would be easier for some actions writer to put together!

k


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

when I check it with Voiceover, whatever I have moved to the front
is read last.

Think of it in terms of creation order, which the stacking order
reflects. The first-created item is back of the stack on the page,
was first on the page, is first in the list, and generated first in
the code. (Shuffling things about doesn’t alter the base logic, it
just alters what is in that ‘position of created first’.)

Looking at the list, it could be argued that top of the list should
equate to top of the stack. But what it does represent is the
logical reflection of ‘position-of-created-first’ in a simple list
format.

What it does show in its top-down running order is the order in
which the code will be generated.

Gotta run - hope this helped!

k


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

I just think it’s backwards. When you move an item to the back, it goes to the top of the list. When you move an item to the front, it goes to the bottom of the list… when I check it with Voiceover, whatever I have moved to the front is read last. It doesn’t make a whole lot of sense to me.

I agree. Items at the top of my page layout, like logo, CSS Menu and heading, I want at the front (and in the case of the CSS Menu it has to be at the front). But items at the front, come last in the source code and are seen last in screen readers and the accessibility preview in Freeway. Yet less important items further down my page (below the fold) come first in the source code and I presume load first - which doesn’t make any sense.

Can anyone shed any more light on this?


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

On 17 Aug 2010, at 11:36, Mark wrote:

I just think it’s backwards. When you move an item to the back, it goes to the top of the list. When you move an item to the front, it goes to the bottom of the list… when I check it with Voiceover, whatever I have moved to the front is read last. It doesn’t make a whole lot of sense to me.

I agree. Items at the top of my page layout, like logo, CSS Menu and heading, I want at the front (and in the case of the CSS Menu it has to be at the front). But items at the front, come last in the source code and are seen last in screen readers and the accessibility preview in Freeway. Yet less important items further down my page (below the fold) come first in the source code and I presume load first - which doesn’t make any sense.

Can anyone shed any more light on this?

In the site panel you have a page (the backmost object) followed by items in order of appearance, starting with the item at the back of the stack and ending with the item at the front of the stack. This bears no relation to the physical order of the items on the page (i.e. an item at the top of the page can be at the front or back of the stack).

In the HTML source code absolute positioned items will appear in the same order as they are stacked in the site panel (items at the back of the stack are written before items at the front) - this can be very bad for accessibility as a heading can be at the bottom of the source code.

Both Table based and relative positioned (either traditional in-flow or new Relative Page Layout) items should appear in order of their appearance on the page (items at the top of the physical page appear before items at the bottom for instance). This is obviously the optimal situation since something programatically reading the page will see text/items in the same order as a human reading the page.

Joe


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Joe

items should appear in order of their appearance on the page (items at the top of the physical page appear before items at the bottom for instance).

That sounds sensible. I need to go back to my file and send items at the top of the physical page (logo, headings etc) towards the back (i.e. appear at the top of the stack list).

The one exception is CSS Menu items. They need to be at the front (i.e. appear at the bottom of the stack list) otherwise the drop down menu options go behind other items, rather than in over the top of them.

Is it just me and Wurliuchi that find this very unintuitive.

Thanks

Mark


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options