Unified style and accessibility upgrades for login, registration, and profile pages

[joemull]

Closes #4380.

Implementation notes

• Brought all pages where a user manages their own account into the back office, and deprecated the theme templates
• Adjusted the admin base as needed to handle unauthenticated users
• Implemented a contextual title element so that the relevant site name is appropriately provided in addition to the page title
• Wrote view tests to make sure new templates are hit
• Used "secondary" style buttons for accessibility (color contrast)
• Adjusted link colors for accessibility (color contrast)
• Improved form accessibility in a few places
• Made heading structure consistent, though I would have preferred not to use h2 for these elements (h1 is taken by the header and used for the site title, which is not ideal in my opinion)

Limitations

• We have got to sort out the heading structure in core/base.html -- it results in two h1s in most cases, and one of them is often empty. My preference is that h1 is used for the actual page, not the site name, and that the site name is simply appended to the title element, so it is available in the browser tab.
  • Update: Created Back office page titles and h1 headings #4503
• The interests field is a consistent accessibility trap, until we can get away from jquery / tagit. We may be able to re-implement this bit of the page as a Django formset

[StephDriver]

Joe, I think something's been missed, this is how I manually tested it:

• log in (works so far, and was taken to new back office log in page)
• select 'Profile' from drop down menu on top right
• was taken to a front of house template, which was themed (testing with ?theme=clean allowed me to change the theme).

either I've misunderstood the scope of this issue, or something's gone wrong. I was expecting the profile page to be back office.

[joemull]

either I've misunderstood the scope of this issue, or something's gone wrong. I was expecting the profile page to be back office.

OK, thanks for testing it. Not sure why you're not seeing the right templates, but I'll go ahead and assign to Andy in case there is something different about the way you're testing it.

[ajrbyers]

Thanks for this, its good to reduce the number of overall templates.

I've added some comments inline. Some more general comments:

• If you enter your username and password incorrectly when the page reloads the form is larger, this feels very strange and should be a consistent experience for the user.
• Can you review all of the comments throughout this PR and ensure they're appropriate. See for example settings.css I don't think the comment here is useful.
• The forms feel a bit lost in the middle of the screen, especially on wider screens.
• These forms introduce a layout system of their own, is there a reason we're not utilising the established layout for the back office here?

[joemull]

If you enter your username and password incorrectly when the page reloads the form is larger, this feels very strange and should be a consistent experience for the user.

The forms feel a bit lost in the middle of the screen, especially on wider screens.

Thanks for these comments and the chat we had, which helped clarify a few things for me. I've opted to left-align everything to be more consistent with other back-office pages, and I've returned to using the title-section element. This puts the semantic name of each of these pages in an h1, which is good (was h2 in the first version), but it means we need to resolve the h1 in the header before this will be accessible, as discussed.

These forms introduce a layout system of their own, is there a reason we're not utilising the established layout for the back office here?

I've tried to use what I can, but there are some float-based components that were not feasible to re-use. I've opted to marginally expand the utilities so that we can develop a framework-agnostic set of layout tools with modern patterns like grid and flex, while we shift frameworks. Let's discuss this more because I have a few things coming down the pike, and I'd like to expand the utilities in the back office more formally.

[StephDriver]

• ✅ log in takes me to the new back office page.
• ✅ failed / rejected log in remains in back office.
• ✅ clicking 'forgotten your password' on new back office log in page takes me to back office
• ❌ clicking 'register' on new back office log in page takes me to front of house
• ❌ register from navigation bar takes me to front of house
• ❌ once logged in, the profile link in account menu from nav bar takes me to front of house

nb. log in looks quite different to me than in the screenshots above:

as per screen share discussion, this could be a domain v path issue.

[joemull]

I still can't replicate this issue @StephDriver. Are we sure your browser isn't caching the old pages?

@mauromsl or @ajrbyers, could you tell me what about Steph's dev setup might cause this issue? I can't think of a scenario in which this view

janeway/src/core/views.py

Line 382 in 042b33e

template = 'admin/core/accounts/register.html'

would return a template under /OLH/ or /clean/ or something else, even if there were a domain / path difference. It should return a 404 if it really can't find the path, not fall back to a path explicitly excluded by the admin bit, right?

[ajrbyers]

@StephDriver let’s find some time to dig around this next week.

[StephDriver]

I still can't replicate this issue @StephDriver. Are we sure your browser isn't caching the old pages?

I don't think so... mostly because I tried it with multiple different browsers and had same results, and there were two pages which loaded the new versions. But I agree it needs further digging... so watch this space.