FLUID-3728: Accessibility of the demo portal

[Cheetham, Anastasia]

FLUID-3728 started out as a JIRA to add an ARIA role of 'application' to the contents of the source-code tabs on the right side of the demo pages. Looking into what would be required to do this, it turns out that the task of making the demo portal more accessible is a bit bigger than that.

I've updated the description of the JIRA to "Improve the accessibility of the demo portal infrastructure" and added comments describing what I've discovered so far. For convenience, these comments are duplicated below.

We need to figure out how much work this task really is and how its priority fits in with other tasks we have on our plate for 1.3.


Comments:


This task turns out to be more involved that simply adding an application role to the tabpanels. There are several deficiencies in the ARIA markup of the page, as well as other issues:

- The "Code View / Plain Text" buttons have no ARIA markup. Semantically, they function as radio buttons and could be marked as such. They are not currently keyboard-accessible as a single set of radio buttons, though they are keyboard accessible as regular links.
- The  "Code View / Plain Text" buttons are currently not actually inside the tab panels (despite the fact that they appear to be). There is a single set of buttons which must work with whichever tab currently happens to be active. This results in some messy code to figure out which tab is active. This could probably be simplified by actually having one set of radio buttons per tab panel, contained within the panel.
- The container of the right side of the page should have a role of application
- With the radio buttons inside the tab panel, the panel itself should have a role of application, and the containers of the actual text themselves should have a role of document
- The various demo 'assets' (i.e. js, html, css files) are loaded separately and independently, requiring some messy code to determine when all of the files are finished loading so that setup can be completed. This would be vastly simplified with fluid.fetchResources() with a single callback.
- There are many hard-coded selectors scattered throughout the code. A DOM binder would make the code easier to work with.
- Event handling code is not well centralized, leading to duplication

Recommended changes:
- Load the assets using fluid.fetchResources() (I've implemented this in my local copy, works fine).
- Restructure the mark-up so that the "Code View / Plain Text" buttons are contained within the tab panels
- Refactor the code to take advantages of more framework features, centralize event handlers, etc.

-- 
Anastasia Cheetham     Inclusive Design Research Centre
acheetham at ocad.ca            Inclusive Design Institute
                                        OCAD University