Accessibility standards

[richard-jones]

It is likely that we will need to comply as much as possible with W3C accessibility standards, e.g. as per this model agreement we are working on:

"Use all reasonable efforts to meet the W3C standards (www.w3.org/WAI/Resources/#in and www.jisc-collections.ac.uk/Guide-for-Publishers/industry_standards/Accessibility-standards) to ensure that the Licensed Material is accessible to all Authorised Users;"

We should review.

[richard-jones]

Incidentally, I've just had a go at the site with a screen reader, and none of the UI is available.

[emanuil-tolev]

Possibly of relevance might be the prerender protocol, mostly used by search engines for SEO purposes.

https://prerender.io/js-seo/angularjs-seo-get-your-site-indexed-and-to-the-top-of-the-search-results/ (less useful, but more meteor-specific) https://juststartworking.com/meteor-and-seo-the-right-way/

Prerender is a glue-tool which enables rendering your pages with phantomjs on the server before sending them to the client (as well as caching appropriately in Redis or as files on AWS S3). Most generally, it works like described here: https://prerender.io/js-seo/angularjs-seo-get-your-site-indexed-and-to-the-top-of-the-search-results/#ifyouusehtml5pushstate

You put this tag <meta name="fragment" content="!"> in your page head, and Google re-requests the page using a slightly different URL (adds a GET param). You capture the request (since it has the extra GET param) at the web server or reverse proxy level, and give it to the prerender software (written in Node). You can buy it hosted at https://prerender.io or host an instance locally, it's open source.

I've installed the local version at Kudos. For example, open this https://www.growkudos.com/?_escaped_fragment_= and see how none of the JS buttons like the Cookie directive will work, but normal links will work.

If screen readers support this concept, they could request a pre-rendered page. There is ongoing work in various frameworks to "rehydrate" the JS on a pre-rendered page, so that it also works normally after pre-rendering.

Provided the big if in the previous paragraph is fulfilled, we could probably build some basic solution that exposed the basics of the site to users (front page, upload file, provide email, hit submit, see results page, download results). The updating results % might be beyond screen reader ability anyway, but we could set an automatic refresh (and warn users about it). We should be able to build this even if meteor's efforts of "rehydratable" JS have not reached maturity - I have not checked.

[markmacgillivray]

Lantern UI is not a meteor site. All we need to meet accessibility is to serve the page as static, which I've already added to the next version of getter. However, the question of accessibility is best answered by considering who may use something and why.

In this case I'd say our UI is functional, not informative. Unless the UI is likely to be used by someone needing a screen reader, what use would it be to ensure it can be used by a screen reader? For example, if a user cannot use excel or other sheet creation tools first, and/or cannot use email clients to be informed of completion, what is the benefit of ensuring a screen reader can be used? The only function of the UI is upload a sheet

• can screen readers allow a user to do this if the upload element is identifiable as one?

On 22 Aug 2016 13:13, "Emanuil Tolev" notifications@github.com wrote:

Possibly of relevance might be the prerender protocol, mostly used by search engines for SEO purposes.

https://prerender.io/js-seo/angularjs-seo-get-your-site- indexed-and-to-the-top-of-the-search-results/ (less useful, but more meteor-specific) https://juststartworking.com/ meteor-and-seo-the-right-way/

Prerender is a glue-tool which enables rendering your pages with phantomjs on the server before sending them to the client (as well as caching appropriately). Most generally, it works like described here: https://prerender.io/js-seo/angularjs-seo-get-your-site- indexed-and-to-the-top-of-the-search-results/#ifyouusehtml5pushstate

You put this tag in your page head, and Google re-requests the page using a slightly different URL (adds a GET param). You capture the request (since it has the extra GET param) at the web server or reverse proxy level, and give it to the prerender software (written in Node). You can buy it hosted at https://prerender.io or host an instance locally, it's open source.

I've installed the local version at Kudos. For example, open this https://www.growkudos.com/?_escaped_fragment_= and see how none of the JS buttons like the Cookie directive will work, but normal links will work.

If screen readers support this concept, they could request a pre-rendered page. There is ongoing work in various frameworks to "rehydrate" the JS on a pre-rendered page, so that it also works normally after pre-rendering.

Provided the big if in the previous paragraph is fulfilled, we could probably build some basic solution that exposed the basics of the site to users (front page, upload file, provide email, hit submit, see results page, download results). The updating results % might be beyond screen reader ability anyway, but we could set an automatic refresh (and warn users about it).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CottageLabs/LanternPM/issues/89#issuecomment-241394365, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuXCOcG2Of863mMCUnHHtiqLHftn0Qzks5qiZJFgaJpZM4JSmfT .

[emanuil-tolev]

Lantern UI is not a meteor site. All we need to meet accessibility is to serve the page as static, which I've already added to the next version of getter.

Ah oops, true, my bad.

I'm sure people who use screen readers can read email and work Excel by now, but the crux really is if they can upload a file. @richard-jones can you try on your screen reader: http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_accept ?

[richard-jones]

Ok, I think the answer probably is just that we need to ensure that a user who does not have javascript or is using a screen reader can meaningfully interact with the page. At the moment, it's just blank (with headers and footers). Even if that's just the addition of a noscript tag with some useful information.