SitePoint Sponsor

User Tag List

Results 1 to 4 of 4
  1. #1
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    74
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    HTML5 outline & accessibility

    Hi there

    Basicly we should use new HTML5 elements in development for new projects. However, what about accessibility when it comes to new elements and outline. Is it also ready now? Read that JAWS tries to understand new outline but it doesn't do it correctly yet. Rest software of that kind don't get it at all.

    I recently started working on project which has quite big user base. I don't have any data about JAWS or other software that is used by the users for the site but I assume there is a chance that it is. What is your recommendation? Should I care and use divs and appropriate <hx /> elements order per page or should I start using header, footer, section, article... and stick to new html5 outline which is many h1 and h2 per page grouped within section content elements?

    What do you think? Is new html5 approach really that painful for JAWS and similar software?

  2. #2
    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)
    Currently it's still recommended to assume that
    - new HTML5 elements' native roles are not mapped (and so when appropriate, use the aria landmark and other roles as a continued stopgap)
    - the HTML5 outline is not seen (or not seen correctly) by the browsers (also, there is talk of maybe just scrapping outline altogether, but I dunno how serious that was)
    - that headings still get manually-set levels


    In other words, if you try to rely on the outline to translate <h1> everywhere to the appropriate levels, you should assume most users of AT will simply see nothing more than lots and lots of h1's, rather than the appropriate levels you intend.

    Since navigation by headings (and heading levels) is an important type of navigation for users of AT, manually using the correct levels is still recommended. For now.

    The real intended benefit of the HTML5 outline was, mostly, for syndication. Is your system going to be incorporating random chunks of user-created data which may have its own complete document-like structure? (For example, complete <articles> or <sections> complete with their own <headers> and <footers> and whatnot?)

    Another thing to keep in mind is, while you can get data for "how does the latest JAWS/whomever deal with [some HTML5 thing]", keep in mind that the commercial AT software out there is expensive, and you can probably assume you'll have users with older versions.
    Users of free/open source versions may be more up to date, of course. But there are more than screen readers: for speech-control programs I only really know of Dragon Naturally Speaking/Dictate/other products, and I don't know of any free version of those. There are also screen magnifiers which may or may not be used with a screen reader... and if used with a screen reader may affect what the screen reader reads out.

  3. #3
    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)
    Quote Originally Posted by xarr
    or should I start using header, footer, section, article..
    I had missed this part.

    I'm cautious with <article> and <section>, especially with recent issues in JAWS/IE. In fact I generally avoid them unless I have a really nice, short document that really reads nicely as a university paper, where bad AT incorrectly announcing each section isn't necessarily too annoying.

    You're pretty ok using <header> <footer>, <aside> and <nav> if you want. Browsers and AT who don't understand them will just see undefined elements, which you'd set as blocks in your CSS, and which you'd add using Javascript for IE <9... and the meaning of these isn't really different from <div> or <span> anyway. On top of that, you can add aria roles to those elements if they are the major headers/footers and nav (you should generally only have one nav anyway per page or application) such as, if appropriate, "banner" for the main page header, "contentinfo" for footer (if it has about-the-site type info in it) and "complementary" (with the e not the i) for asides if that matches their content. There are some older versions of screen readers who, with a new enough browser, recognise these elements but then screws something up inside. Recently JAWS seems to have been going through a rapid development rate and I wonder how many people are on versions like 11. People who rarely upgrade would likely be on something much older... people who are able to keep up to date would hopefully have 13 or 14. Or I'm just being hopeful : )

    I personally feel mostly safe using the elements who aren't section and article, but this would be decided per project. Since these are wrapping elements, it's still generally more important to get the stuff inside right. If you thought your userbase was really going to have a really high concentration of folks using things like older browsers or in enterprise (office with old Windows) environments, then it may still be safer to stick to divs, which I am doing for our e-commerce packages (too many IE7 on Windows XP right now).

  4. #4
    Non-Member
    Join Date
    Aug 2013
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    These are the sorts of decisions we don't want and shouldn't have to make when building accessible web pages, but they are a reality that we unfortunately get used to. On the other hand, screen reader and browser development is moving very quickly these days, so this particular problem may not exist for long.


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
  •