SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 38

Hybrid View

  1. #1
    SitePoint Addict
    Join Date
    Mar 2010
    Location
    UK
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Page (and heading) structure conundrum

    I want to include headings, positioned off-screen, inside major page divisions such as the navigation and footer. To me, it makes a lot of sense to improve ease of use by providing these extra "hooks" (for want of a better word) by which I know that a lot of vision-limited users navigate when they use assistive software. I imagine that it would also improve their understanding of the page structure and content. Win-win (for those users, at least).

    The trouble for me is in dealing with anything that sits above the main content (and its H1) in the HTML. My current structure is simple and minimal. At the very top, I have skip links; then a position:fixed vertical menu on the left with the main content to the right of it, and nothing else except a footer:
    HTML Code:
    <div id="skip-links">skip links in a UL</div>
    <div id="navigation">main menu items in a UL</div>
    <div id="content">
    <h1>main title</h1>
    main content...
    </div>
    and a simple footer div...
    As far as I can see, I have limited options. (a) Move the main menu to below the main content and change the skip links to suit. This would not alter its screen position but I have major reservations about this unconventional HTML layout that would not match the screen layout. And the skip links couldn't receive a heading in that case, though that might not be a huge issue. (b) Be slack with heading hierarchy and use lower-numbered headings in the divs above the content. Again, I'm not keen on that. (c) Move the H1 up in the HTML, above the skip links, and somehow work around or correct the HTML/screen order (because the H1 ideally needs to be below the skip links so that it's directly above the content: this makes much more sense to me). (d) Put a generic website title in an H1 and use an H2 for the content's title. I know that some sites do that, but I hate it: making the most important heading a generic title or logo? It just doesn't make sense to me. (e) Who knows...

    I need recommendations and counsel, please folks! How do you solve layout issues like this in a way that ticks all the boxes: semantic HTML, tidy structure, matching HTML/screen order, meaningful content, helping all users...

  2. #2
    SitePoint Wizard bronze trophy Tyssen's Avatar
    Join Date
    Oct 2005
    Location
    Brisbane, QLD
    Posts
    4,067
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't generally bother with a heading for the main navigation on the page because it's a fairly common practice for it to be near the top of the page so it should be fairly obvious to most people (sighted or otherwise) what it is when they encounter it. I'd only bother with headings for navigation if they appeared in other places of the layout.

    You can also add extra accessibility and semantic meaning to your elements by using ARIA landmark roles, like <ul role=navigation> which is something that I do.

  3. #3
    SitePoint Addict
    Join Date
    Mar 2010
    Location
    UK
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, I have landmarks in place. Regarding the headings: do you not think that they also aid in-page navigation for screen reader users? I know that they are often used in that way, so if they are also useful for reaching the navigation and footer, that would seem to be a strong reason for using them in most, if not all, major segments.

  4. #4
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,266
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    do you not think that they also aid in-page navigation for screen reader users?
    They can; header-navigation is one of the easiest ways to bop around in a page. But I agree with Tyssen: you're overdoing it here. People have access to the beginning and end of the page: the skip links are the first content on the site; heading them is unconventional and unnecessary.

    I don't "head" my skip links and I usually don't "head" my main menu (unless, as Tyssen mentioned, there are other menus... complex sites may have a "main" navigation menu (which I would give a role of "nav" to), a "sub" navigation (less important but still site-wide links, like privacy, terms&conditions, press releases, investor relations... and this nav might be in the footer), a "products" menu for sites who sell many products, etc) because, as Tyssen said, the main menu is fantastically obvious and users have numerous ways of navigating it. Headers are Good, but Being Too Chatty can reduce accessibility. There's a clever term for this (too much accessibility) but it escapes me. In any case, it can become annoying quickly.

    Users who want to get straight to the main content have many options:
    -they can use your skip links (see Safari note below); so make the link text obvious that it's for skipping
    -they can call up all the lists of links on the page, and select the second one (main nav) and then Next Non-Link Text (this would be your h1)
    -they can use h or h-1
    -they can go directly to the role of "main" that you'll have on your content div
    -they can go do the role of "nav" and then Next Non-Link Text

    Lots of options. Most sites don't head skip navs or main navs, meaning these other methods of moving around them aren't lost on experienced users. I would expect less-experienced screen reader users to use the skip links heavily... so a link to your footer would not be a bad idea. Also, skip links are still pretty cool for sighted keyboarders... so have that text appear onscreen on :focus.

    A note on the "using skip links to move focus down the page": this won't work in Safari, which means it won't work for VoiceOver users who don't use Firefox or some other browser. Safari moves the visual focus down when clicking on a skip link whose destination is an id attribute, but it won't move the keyboard focus. If you want to ensure VO users using Safari get real skip links, you'll need to embed something clickable at the skip destinations. I use empty anchors inside the elements whose id's the other browsers are using.

    Opera sometimes won't do this either, but I forget the rule for Opera (and I worry much less about skip links in Opera: it's trickier to use with many screen readers and Opera offers spatial navigation for sighted keyboarders, meaning they have more freedom to move where they want than users of other browsers).

    I personally would say heading the skip link nav is Too Much and heading the main nav is being Captain Obvious.

    Having a skip link to your footer is good/fine if there's a nav in there, using role=complementary is good, heading it is something I'd only do if I had a Fat Footer (those ginormous things people manage to call footers but are like half the site page crammed with information... and may have multiple headers inside them!).

    This would not alter its screen position but I have major reservations about this unconventional HTML layout that would not match the screen layout.
    While I agree with your conclusion (don't move the main navigation to an unconventional order in the markup), whenever you start playing with position: fixed, that kind of talk gets nowhere fast, because screen layout becomes disconnected with any sort of reality anyway. I had a layout with main navigation in a fixed footer (but also, really in the footer) and even setting up skip links at the start of the page, I was pretty sure people would get confused. I just didn't have any authority to re-arrange that page though.

  5. #5
    SitePoint Addict
    Join Date
    Mar 2010
    Location
    UK
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No, I wasn't going to add a heading to the skip links (I should have clarified that), but I thought that the main menu and, most of all, the footer could benefit from it. I was looking at what the 456 Berea St website has and figured that this would be representative of best practice. Although, as with so many things, there is probably much more than just one "correct" answer.

    Re: the skip links; I have one going to the footer, which has quite a lot of supplementary links (privacy, terms, archive, etc.) and content in it. Not a ridiculous amount, but it makes it a major content section.

    Re: the fixed main menu; is it OK to do this if its initial position on-screen pretty much reflects its position in the HTML? On-screen, it's lined up to the left of the H1 (and its subsequent content) with the skip links appearing above these two sections. I just like having it fixed because I appreciate the convenience when browsing.

    Thanks for your input.

  6. #6
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,266
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    No, I wasn't going to add a heading to the skip links (I should have clarified that)
    ok
    but I thought that the main menu and, most of all, the footer could benefit from it.
    Yeah, if your footer has enough content to be headed, a header in the footer can be a good idea.

    I was looking at what the 456 Berea St website has and figured that this would be representative of best practice. Although, as with so many things, there is probably much more than just one "correct" answer.
    Hm, I definitely can't say Roger's site isn't best practice! Roger likely added the header specifically for navigation purposes, for a few reasons:
    - there's actually stuff in the way between the skip link and the navigation (including a search form)
    - and he hid the header because whether CSS is on or off, his main navigation is obviously obvious main navigation.

    It still seems a little overboard to me but with that search form in there, it's probably nice to have. Also, he's mixing HTML5 stuff and wrapping excessively with divs for the browsers/UAs who aren't HTML5-ready yet, and so he's probably using the hidden headers as counterparts to the roles (since olders UAs don't understand roles and users won't be able to use them for navigating). His code might be a bit of a purposeful showcase in that regard.

    On this site: http://juicystudio.com/ you see Gez has a lot of content coming before the navigation, and does the same thing as Roger, except he left it out in the open because its position makes it somewhat less obvious. I would otherwise completely rely on his CSS to easily find the menu.
    If you were still thinking of having your nav in the footer (or a sidebar), then not only would a header be okay but I'd even consider leaving it out in the open for everyone.

    http://lflegal.com/ which was done by Mike Cherim (who on his own blog had headers before the navigation, which is actually probably the place I first saw this technique) and was one of the two first sites to pass Vision Austraila's WCAG2 tests, also uses header navigation— but like Gez' site, the navigation is after a bunch of other content, and keeps the header onscreen.
    Interestingly, there are also headings (hidden) for the breadcrumbs and some extra text ("You're exploring").

    Mike Paciello's blog page http://www.paciellogroup.com/blog/ doesn't use hidden headers above the navigation but, looking at the page, the navigation doesn't look like the main course of anyone's navigating.

    I dunno, I can see the arguments for headers before main navigation, but personally (yeah, opinion) it's a little more than necessary.

    Re: the fixed main menu; is it OK to do this if its initial position on-screen pretty much reflects its position in the HTML? On-screen, it's lined up to the left of the H1 (and its subsequent content) with the skip links appearing above these two sections. I just like having it fixed because I appreciate the convenience when browsing.
    It's probably ok. I mean, if you're thinking of screen readers, it doesn't matter where you set it with fixed positioning. If you mean everyone else, it's probably okay but you could always ask users for feedback or do user testing.

  7. #7
    SitePoint Addict
    Join Date
    Mar 2010
    Location
    UK
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks, Stomme. Much appreciated.

  8. #8
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    I really don't think putting the h1 before the accessibility menus is a big deal -- it's ONE MALFING LINE. Hoody-hoo!

    Though, just to rag on you a bit (not entirely serious -- not sure if those are placeholders or if you'll have them in the final code) if the accessibility menu going to be a UL, why have the DIV? If the main menu is going to be a UL, why have the DIV? Both are perfectly good block-level containers so don't waste a div on them for NOTHING -- especially the one you won't display for screen/print.

    Though I would NOT position them offscreen. Display:none is typically fine if you put accesskeys on them with title attributes.

    Check out Home - DEATHSHADOW PASCAL in Opera (excuse the green, it's a retrocomputing joke) and hit shift-esc to pull up the accesskeys menu.

    I usually rag on people for "pointless" title attributes -- if the title is the same as the content inside the element, there is NO reason to put title on it... unless you have accesskeys! Then it actually does something useful.

    Though that really comes down to do you want screen reader users to hear them or not -- I've actually had screen reader users complain about their presence which is why I display:none them for media="screen,projection,tv" but leave them alone for "handheld" where they are useful... and of course CSS off browser users love them too.

    Really though, if you are practicing separation of presentation from content how does it look without the CSS? There's a reason I advocate coding the entire markup semantically before even THINKING about appearance/layout.

  9. #9
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Though I would NOT position them offscreen. Display:none is typically fine if you put accesskeys on them with title attributes.
    A lot of screen readers won't read things out that are display: none, so it kind of defeats the whole point!

  10. #10
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    A lot of screen readers won't read things out that are display: none, so it kind of defeats the whole point!
    read paragraph 6... the one starting "Though that really comes down to"

  11. #11
    SitePoint Addict
    Join Date
    Mar 2010
    Location
    UK
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    I really don't think putting the h1 before the accessibility menus is a big deal -- it's ONE MALFING LINE. Hoody-hoo!
    You have an obnoxious attitude. Do you respond to everyone like that, including fellow pros, colleagues, and clients; or is it just an attitude that is reserved for hobbyists and novices? Way to put people off asking questions.

    To answer your question: it is primarily about figuring out how to position the H1 in visual relation to the content division in which it currently resides, if it ends up not actually being in there. Such things as this are still open to development. It should be in there, to my mind. I don't want two navigation lists in between the H1 and its sub-heading: that just seems odd and messy. And I hate messy.

    Though, just to rag on you a bit (not entirely serious -- not sure if those are placeholders or if you'll have them in the final code) if the accessibility menu going to be a UL, why have the DIV? If the main menu is going to be a UL, why have the DIV? Both are perfectly good block-level containers so don't waste a div on them for NOTHING -- especially the one you won't display for screen/print.
    In the case of the main nav list, it is a way to conveniently/reliably position a list AND a heading together in a particular part of the page. Which is to the left of the content in this case, as I already mentioned. If I don't use a heading above the main nav, then I won't need to use the div and I might remove it.

    In the case of the skip links list, the div contains, or will eventually contain, a logo and/or website title. Again, it might be removed later if the design doesn't need it. But at the end of the day, if I want to use a div, I will.

    Quote Originally Posted by deathshadow60 View Post
    Which is what I assumed OP was asking about... and why the 'screen reader' part of it made little if any sense.
    Don't assume. If you were not sure what I meant, you could have taken the time to ask.

  12. #12
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by adh32 View Post
    You have an obnoxious attitude. Do you respond to everyone like that, including fellow pros, colleagues, and clients; or is it just an attitude that is reserved for hobbyists and novices? Way to put people off asking questions.
    Don't take it personally... DS deals with everyone on the forum in the same way unfortunately!

  13. #13
    SitePoint Addict
    Join Date
    Mar 2010
    Location
    UK
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    Don't take it personally... DS deals with everyone on the forum in the same way unfortunately!
    Yes, I've noticed. Sitepoint is too soft on that kind of thing.

  14. #14
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,266
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Stomme poes: you mentioned that only some browsers can use links that point to IDs. Can you elaborate a bit about that? I thought that all browsers can do this. The ones that I've tried so far can.
    Safari. Try it. If you have Windows, Safari-for-Windows is the same.
    The visual focus will move!
    But the next "tab" you make will have you starting back where you were, not where you skipped to.
    This actually kinda makes sense. How do other browsers bring focus "down" somewhere on a page when there's no element for that browser to focus on? But somehow most browsers get it right. Safari doesn't.

    Arg, I can't find the WebAim PDF, it's somewhere on their site: they have a WWF smackdown-style comparison of some screen readers. They have VoiceOver failing skip links, but it's really because of Safari, not VO.

  15. #15
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    You were talking about title attributes at that point!

  16. #16
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    You were talking about title attributes at that point!
    There's more than one sentence... Literacy much? "display:none" is only IN the second sentence and all...

  17. #17
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,266
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Though that really comes down to do you want screen reader users to hear them or not -- I've actually had screen reader users complain about their presence which is why I display:none them for media="screen,projection,tv" but leave them alone for "handheld" where they are useful... and of course CSS off browser users love them too.
    That defeats the purpose then doesn't it (the purpose according to the OP is using them for navigation)?

    My posts above agree with your concern that adding headers everywhere may make the page "chatty" (which experienced screen reader users find more than annoying), BUT if you're going to add them in anyway, then make them heard.

    There's zero point in having them in there and also display: none, unless they're being added for teh Googles. And I don't add crap special for them, they're the least important visitor in my view.

    Though the handheld idea, that one's good (I hide stuff in my desktop.css that isn't hidden in the handheld css) but I don't hide from screen reader users.

    One reason being, how do I know the visitor is experienced? Screen reader n00bs do everything slowly, they make generous use of skip links, and they are often tabbing/arrowing through everything instead of using more advanced navigation. So I try not to overdo it with headers, but if I'm gonna waffle anyway and add them in, I know those who really don't need them likely also know how to skip them anyway.

    Titles: you can't know people turned "read titles" on. It may be default in their reader... it may not. Or they may have turned them off explicitly because so many sites throw titles around everywhere (as you said). Only place I trust titles is in form controls (inputs, this is when for some *good* reason there isn't an explicit label), and there's one popular reader who still ignores them (Orca).

  18. #18
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    That defeats the purpose then doesn't it (the purpose according to the OP is using them for navigation)?
    There are things OTHER than screen readers; like handhelds which is what the original point of such menus was supposed to be; I find it odd to even find people talking about screen readers for such a thing -- since they generally navigate the heading structure. (which is why I'm such a stickler for proper heading orders).

    Quote Originally Posted by Stomme poes View Post
    There's zero point in having them in there and also display: none, unless they're being added for teh Googles.
    HANDHELD, SMALL SCREEN. HANDHELD, SMALL SCREEN!!! Bandwidth locked text only on Blazer or similar...

    Especially when, as I mentioned, the device lets you use an accesskeys menu.

    Quote Originally Posted by Stomme poes View Post
    Titles: you can't know people turned "read titles" on. It may be default in their reader... it may not. Or they may have turned them off explicitly because so many sites throw titles around everywhere (as you said). Only place I trust titles is in form controls (inputs, this is when for some *good* reason there isn't an explicit label), and there's one popular reader who still ignores them (Orca).
    90% of the time people use title attributes there's no good reason for it. I've said it a billion times if you NEED a title attribute and you aren't using accesskeys, there's something HORRIBLY WRONG with the content of the element. This is particularly true of anchors...

    REALLY true when you see people putting title attributes on an anchor that's identical to the content of the anchor! /FAIL/ hard. (Yes turdpress, I'm looking at you!)

    For example:

    <a href="/" title="home">Home</a>

    == Go back and learn how to write HTML!

  19. #19
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,266
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    HANDHELD, SMALL SCREEN. HANDHELD, SMALL SCREEN!!! Bandwidth locked text only on Blazer or similar...

    Especially when, as I mentioned, the device lets you use an accesskeys menu.
    Are you claiming people using handhelds need headers to tell them what's a menu?
    I certainly don't add extraneous headers for handhelds. If you need a header before your main menu then your menu isn't obvious (which is fine, this is true in most of the examples I listed earlier... the menu was nowhere near the top of the page and needed a header... ONSCREEN for EVERYONE in most cases).
    The OP asked if more headers should be added to the page specifically for screen reader navigation more than anything else... that's what most of our answers in this thread were about.

    And I don't touch accesskeys with a 10-foot pole. I realise large sites who are constantly revisited by people do (like SitePoint and BBC) but I will not add them to any of my pages.

    Someone twotted a web site at me and said "like your browser shortcuts getting fux0red?" Now I couldn't see what he was talking about at first 'cause it turned out someone was retarded and used Javascript but anyway they hijacked CTRL-L to bring up some annoying modal popup thing (instead of letting us bring focus to our addressbar). I don't touch accesskeys because I'm not going to memorize the 500 different key combinations possible on every OS and browser just to make sure I don't accidentally interfere with someone's built-in shortcuts. Yeah, even if I stick to numbers like BBC.

    But that's me.

    REALLY true when you see people putting title attributes on an anchor that's identical to the content of the anchor! /FAIL/ hard. (Yes turdpress, I'm looking at you!)

    For example:

    <a href="/" title="home">Home</a>

    == Go back and learn how to write HTML!
    Yeah, I caught someone using Drupal with one of these. Title text would have been great taglines for the pages the anchors linked to, but it was ridiculous on anchors.

    I wonder if most CMSes out there are adding title="" and prompting people to fill them in?? Arg arg.

  20. #20
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Yeh, I was wondering why these were needed for handheld device... maybe 10 years ago when WAP was all the rage, but not any more!

  21. #21
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,266
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Yeh, I was wondering why these were needed for handheld device... maybe 10 years ago when WAP was all the rage, but not any more!
    Well, if a section of content is relying on desktop styling to make it obvious to users what it is, a header is a good idea... but then, a header should have been there in the first place anyway. Looking at Gez Lemon's page, again, I would need CSS styling to find the navigation menu (it's surprisingly easy to miss, at least for me). I actually found it first by searching in the source, and then /Site Navigation to search for that text in my browser, which highlighted the header above the navigation.

  22. #22
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Modern handheld devices all support CSS though... so anything you'd see on a desktop browser, you should see on the mobile one anyway.

  23. #23
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    Modern handheld devices all support CSS though... so anything you'd see on a desktop browser, you should see on the mobile one anyway.
    SOME CSS.... and not everyone is going out for the monster data plans with the $400 a pop devices (or two hundred dollar a month data plans) so there's plenty of people still using Opera Mini, Opera Mobile, and Blazer. (in fact, aren't the majority of handheld users STILL using Opera in one form or another?)

    ... and "anything you'd see on a desktop"?!?!? Sure, that 240x320 display is SO useful on those idiotic 1024 fixed width layouts... Someone on a droid phone is going to disagree with that one a hell of a lot...

  24. #24
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,266
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    I'm saying if you make a skipto/jumpto/accesskeys menu for ON PAGE navigation, that's mostly for handheld users where it's REALLY useful on the pathetically small display; like in Blazer, Opera Mobile or Opera mini.
    Ok, I thought you meant header tags. Skip links: I don't make them so much for screen reader users as I do for sighted keyboarders of any sort. Mobiles count as this.

    I think you completely missed what I was saying or something.
    Yes but I think I got it now.

    Which is wierd -- that's not who I ever heard of them being for. Acessibility aid, certainly, but not for screen readers...
    Yup, just about every major screen reader lets you hit a quick key (usually "h") to move to the next header (or shift+h, previous header, or choose a number to reach next/prev header of a certain level... which is why the HTML5 let-sections-determine-header-levels might be a disaster). Header-based navigation is so, so nice in a screen reader. It pretty much lets you skim any well-structured page.
    Here's a video of a guy using JAWS 9 and header navigation
    But NVDA and Orca and I believe Window-Eyes do exactly the same thing.
    Since I learned how to navigate in JAWS via keyboard better than I ever bothered to learn keyboarding in any of my browsers, it's become preferred when I'm testing my sites' keyboardability anways.
    I know when I'm stuck on a small display they're a HUGE help for skipping around the page rather than the PAINFUL scrolling through trying to find things. Hell, I even use them on desktop on occasion since Opera supports them properly.
    Are you talking about header tags here? Opera lets you skip by headers just by itself? If so, this is pretty cool but totally new to me.
    I suspect you're not so some code demonstrating what you mean would be nice.

    (in fact, aren't the majority of handheld users STILL using Opera in one form or another?)
    I think it was pretty close to the top, though with Nokia still being most popular phone worldwide, their browser that came with Symbian (webkit based in some way) may be at the top.

    so anything you'd see on a desktop browser, you should see on the mobile one anyway.
    I agree with Crusty on this, simply because the stuff you see on sites geared for desktop are often just... wow, wth? Way overboard. But, I like the idea that's slowly circulating around the web evangelistas... that if people are preferring your "mobile version" or using Readability plugin on your site, you have too much for "desktop" in the first place.

    Getting heavily off-topic, but if you're building "mobile first" (or, simple basic everything-works-but-no-BS site) then layering desktop bloat^H^H^H erm "enhancements" on top... that should help avoid adding unnecessary desktop swill to mobiles and/or small screen.

    Headers, though... If I've got them in the markup, they generally always show up on mobile/small screen. Mostly because I save most of the CSS hiding/showing/JS/CSShover stuff for larger screens, which may or may not hit iPads (I don't care) but is meant for people expecting traditional desktop stuff. And if the headers were there to assist in screen reader or low-css navigation, if they get hidden at all it's only on the "desktop" styles.

  25. #25
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Yup, just about every major screen reader lets you hit a quick key (usually "h") to move to the next header (or shift+h, previous header, or choose a number to reach next/prev header of a certain level... which is why the HTML5 let-sections-determine-header-levels might be a disaster). Header-based navigation is so, so nice in a screen reader.
    Exactly -- that's what I meant above when I said "screen reader users usually just navigate headings" (or something to that effect)... hence why I set them to display:none as I have proper heading orders for them already.

    Heck, most of the time the ID's the .jumpto/.skipto/accesskeys menus point to are right next to the headings... it's a method for keyboard navigation on browsers that don't support headings.

    Which is what I assumed OP was asking about... and why the 'screen reader' part of it made little if any sense.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •