Community
Participate
Working Groups
In discussing Orion accessibility issues with Carolyn, she mentioned the HTML5 section elements, such as header, footer, etc. Some assistive technologies may make use of these semantic tags, so we need to think about whether we should be using them in our page markup. Some blog posts suggest that using existing (landmark) roles may cover everything. http://www.paciellogroup.com/blog/2011/03/html5-accessibility-chops-section-elements/ Carolyn will provide links/advice on this issue.
It seems that, for now, the recommendation is to use the new HTML5 tags in conjunction with ARIA roles. The link Susan added in comment 0 and the following link, which has sample screen reader output (from January 2011), basically say the same thing: http://cssgallery.info/how-screen-readers-speak-a-page-with-html5-and-aria/
Good ARIA landmark role/HTML5 structural elements comparison table here: http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/#table1
Recent table (Nov/11) showing screen reader support of ARIA landmark roles. http://www.html5accessibility.com/tests/landmarks.html Bottom line is that the screen reader support is there (the notable exception being Window Eyes). The links don't mention Orca (the Linux screen reader) however a web search shows that it does support ARIA landmark roles.
I've made an initial attempt at adding the HTML5 elements and ARIA roles. Hopefully I got them all. Here is the commit (in the bug365363 branch). https://github.com/max-li/orion.client/commit/825de9f286773c9ea62f4526c924b44161f26c47
Thanks, Max. It so happens that the common header fragments moved to a new file the same day of this patch, but I think I can handle a manual merge. What behaviors change (if any) change when adding these roles and no screen reader is present? We are in the end game of a release so I want to understand the possible risks before adopting this now (vs. early in next release).
Nothing at all should change when not using a screen reader.
will look at this for RC1
I suspect it doesn't matter from an accessibility perspective, but I thought some of our divs would also become <section> or even <article> elements. I guess until we have concrete uses for making the distinction we can just focus on the ones that impact accessibility (calling out header, footer, and nav elements).
(In reply to comment #8) > I suspect it doesn't matter from an accessibility perspective, but I thought > some of our divs would also become <section> or even <article> elements. I > guess until we have concrete uses for making the distinction we can just focus > on the ones that impact accessibility (calling out header, footer, and nav > elements). yes. The new "sectional style" pages such as the repo page I believe are already using sections. I'd like to see us use "sections" for any sub-pane on a page, but I think that's a semantic thing and also not a 0.4 thing.
Regarding <section> and <article>, while they are not technically "landmarks" (they are "structural elements"), JAWS considers them to be landmarks and treats them in a similar way: announcing when the user enters and leaves them, and providing navigation to them with the "next landmark" (;), "previous landmark" (shift+;) and "list landmarks" (ctrl+ins+;) keyboard commands. In order for this to work, you need to use both the HTML5 tag and the ARIA role, for example: <section role="region"> <article role="article"> Here's a reasonably current slide presentation on how the latest versions of several popular screen readers handle HTML5 and ARIA landmark roles. The best results always come from specifying both the HTML5 element and the corresponding ARIA role. Please note page 9 of this presentation, which can basically be used as a quick-reference page for coding the HTML5 elements with accessibility in mind. http://environmentsforhumans.com/2011/accessibility-summit/presentations/Kiss-a11ysummit-screenreaders.pdf
I've added section elements and region roles to pages where I believe they're appropriate. I've put the changes in the following commit (in the bug365363sections branch). https://github.com/max-li/orion.client/commit/be0689df2f50cf217daea34c9939a3973d40cb5f
(In reply to comment #11) > I've added section elements and region roles to pages where I believe they're > appropriate. > > I've put the changes in the following commit (in the bug365363sections branch). > > https://github.com/max-li/orion.client/commit/be0689df2f50cf217daea34c9939a3973d40cb5f Wow, thanks Max. From a release 0.4 point of view, I first intend to fix bug 367220 because it deals with sections and common section behavior. Having done this, it will become clearer whether the fix you propose is necessary or not. I'm trying to get it where the code that needs "a pane" calls common code to create the proper template rather than each do it their own way. We need to get all the 0.4 functionality in and then revisit this bug and see how far we want to go in this release.
Max, there are some big commits coming in today (hopefully) in settings and other places. A lot has changed. So I'm going to ask you for a single commit for this bug that is merged with the latest (NOT YET...please wait for a ping). Sorry to have to ask for that, but we've got to get the RC1 committed fixes in first and then revisit what we want to do here. Please stand by.... (thanks!)
i think the churn is limited gain for 0.4, lets hit this early in 0.5. Sorry, Max. I indeed appreciate the effort but I don't feel confident we could flesh out unintended side effects releasing this during the RC's. I will ping when we want to look at this.
(In reply to comment #14) > i think the churn is limited gain for 0.4, lets hit this early in 0.5. > Sorry, Max. I indeed appreciate the effort but I don't feel confident we could > flesh out unintended side effects releasing this during the RC's. > > I will ping when we want to look at this. ping. Assigning to max. I know he's done some work on this in other bugs.
Fixed with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=b1063ea6166bdd6261d99be0f828f6bc8c7a6a43
(In reply to comment #16) > Fixed with > > http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=b1063ea6166bdd6261d99be0f828f6bc8c7a6a43 thanks, Max, for preparing this again!!
