17 Review and adjust the application layout for accessibility

[Captainkirkdawson]

Priority 17 (2 3 8 4)

The Application layout provides a template within which all other pages are displayed. This template must conform to all accessibility requirements. Review against accessibility report and adjust as required

[AlOneill]

Don't see how this can be sensibly done until pages using current version of tooltips have been adjusted to avoid use of links and instances of tabindex="n", where n is bigger than 0 (zero), have been removed.

[Captainkirkdawson]

Not sure I follow that.

To the best of my knowledge the application layout which is controlled by the following 4 partials does not use tool tips.

https://github.com/FreeUKGen/MyopicVicar/tree/master/app/views/layouts

Every page displayed by FR is done within this layout. It needs to be fully "accessible" and set up so that the "yield" of all page partials start correctly. If there are problems here then everything else will be incorrect. This likely can be tested by setting up 2 test pages (1 in refinery and 1 in ruby) that have a minimal amount of information but exist to confirm that the layout is correct.

[AlOneill]

Not the partials themselves, but if they are used to contain, say, the Search 'page' and similar, then the 'page' itself has to be suitable.

Unless all the forms and results 'pages' use a different set of partials??

Will send you a screenshot, Kirk, to show the kind of weirdness a keyboard-only user would see if the partials were edited first.

[Captainkirkdawson]

I agree the pages themselves have to be correct ie the Search Page has to be correct but the point is if the partials are incorrect then or do not support accessibility properly then they can destroy a good page. All pages/forms/displays are rendered by https://github.com/FreeUKGen/MyopicVicar/blob/master/app/views/layouts/application.html.erb#L89-L100 within a page setup by the application layout.

[AlOneill]

I see what you mean, but the reverse is also true! Certainly would not want to deploy improved partials on production server unless the tooltip-using pages are also improved to match. Will think on ...

[Captainkirkdawson]

We agree both parts have to be correct. The layout and the specific form/page/result.

Since the layout affects all pages I feel it should be our number one priority. Followed by the Search Form as that is our landing page.

[AlOneill]

The reason for caution is exactly that -- the layout affects all pages. Having a skiplink on any page promises accessibility that cannot be delivered until the other pieces of the jigsaw (the page content) are in place, working as promised/expected.

[Captainkirkdawson]

@AlOneill is this still open and a requirement

[AlOneill]

@Captainkirkdawson Yes, still open. Yes, a requirement. Cannot be done until CSS changes are in place — otherwise skiplinks would be visible all the time, whereas they need to be invisible until tabbed into.

[PatReynolds]

@AlOneill is this something that we have addressed and can be closed? Or is it still needed?

[AlOneill]

@PatReynolds This appears to be about providing a skiplink: if there is no other more specific story for a skiplink, then this needs to remain open.

The whole question of skiplinks is made more difficult because of all the adverts we carry — they take a lot of tabbing to get past and they are placed in a variety of locations.

An initial skiplink (at the very top of every page) would be fairly straightforward — it would be in the same place on every page and allow a keyboard-only user to by-pass the top advert and main navigation. (Note that the FUG WordPress site has such a skiplink.)

[PatReynolds]

Thanks, @AlOneill I could have sworn I remembered you and Kirk talking about this in a scrum over the last few weeks, but can't see a story anywhere so won't touch this one.