Hackage's search and package pages are no longer accessible

[Merivuokko]

A recent update broke Hackage's accessibility. Search and package pages no longer work with browsers which do not have support for JavaScript execution. Such browsers include Lynx and Elinks, which are commonly used by blind users.

Possible workarounds include: 1) provide the original content of these pages within a section, and 2) provide separate accessible pages for non-JS browsers.

On Unix-derivatives blind users are not able to switch over to JS-supporting browsers, as the graphical screen reading software on these platforms is inferior.

To date hackage has been an exceptionally accessible site, and I wish to see this support continued.

[gbaz]

cc: @ysangkok

[ysangkok]

The old search could indeed be restored by partially reverting b6abd00 and d3ac12a, and having the old code available on alternative endpoints. I suppose that would be the easiest way. I could do this next weekend, would you like that @gbaz ?

[Merivuokko]

I tested the new pages with Lynx (I previously used Elinks) and I found out, that the package pages work with Lynx. So with package pages the issue is something else than JS – probably a redirection issue.

If I direct Elinks to https://hackage.haskell.org/package/containers, I et the following kind of JSON as a response:

{"0.1.0.0":"normal","0.1.0.1":"normal","0.2.0.0":"normal","0.2.0.1":"normal","0.3.0.0":"normal", ...}

If I load the same URL with Lynx, I get a warning:

Alert!: HREF in BASE tag is not an absolute URL.

But then the page loads fine.

[gbaz]

I think the former issue (elinks) is because there is now a json content type and hackage server will default to it in this specific instance if a browser does not specify a desired content type. I find it weird that elinks doesn't send a content-type tag, but perhaps this should encourage us to enforce that the "default content type" is always text/html if it exists.

Not sure about the base tag issue -- prs welcome.

Vis a vis putting the old code on alternative endpoints -- I suppose this is ok. I would much prefer we had a path that enabled new search but computing the results on the server side rather than the browser, but I understand if that would be rather too much work...

[ysangkok]

The HTML versions of the package pages did not have any JavaScript added, in fact a bit of JavaScript was removed as part of #1022. But you are correct that the browse and search pages now require JavaScript. This could be restored as previously mentioned.

Here is how to reproduce the default content-type issue pointed out by @gbaz:

$ curl -s -D - "https://hackage.haskell.org/package/containers" | grep -i Content-type
Content-Type: application/json
$ curl -s -D - -H "Accept: text/html" "https://hackage.haskell.org/package/containers" | grep -i Content-type
Content-Type: text/html; charset=utf-8

This is a bit curious since the recent PR #996 by @Kleidukos was meant to default to text/html: relevant code change. But really I think that browsers that try to parse HTML should send a header that signals that.

[ysangkok]

Ok, I have written some code for this that I will submit after #1049 is in. Here it is: https://github.com/ysangkok/hackage-server/commit/597e8cdb9693e19227853d14fad1b1898c2bc541.

[gbaz]

merged the above pr

[gbaz]

Also would appreciate if you could figure out why the content-type fix doesn't work, though as you say it shouldn't be an issue for basically any modern browser.

[ysangkok]

Sure! I'll make sure Elinks support is improved. I do think it would be appropriate to have two different PRs for these fixes. I'll get the noscript search PR out tonight, so in about 8 hours.