Admin accessibility

[Tom Carrick]

Sorry, long post incoming.

The admin currently has some accessibility issues. Not a huge amount,
actually, but they should be fixed regardless. I hope I don't need to
convince anyone here of the importance of accessibility, but I'll try to
make the case as briefly as possible for the benefit of the wider community.

There is a trend towards stronger accessibility laws - there is a good
roundup of them here: https://www.w3.org/WAI/policies/ - and I'll come back
to this later. Most of these cover the public sector and small segments of
the private sector, but there's also an overview of some laws used against
private entities more generally here:
https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines#Legal_obligations

I should make it clear that I'm not a lawyer and have no idea if any of
this would apply to the admin, since it's not intended for general
consumption, so I think I'd rather make this point: Developers and other
people using the admin - "staff users" of some kind - can have disabilities
too, and we should be catering for them, especially since the remedies are
not at all difficult. It's also worth pointing out that accessibility
improvements almost always improve the general experience. For example,
making sure everything is easily accessible for keyboard only users is also
beneficial to power users. Better contrast and larger fonts are more
legible for everyone, not just for those with low vision, etc.

So I think the place to start here is to decide on a guideline to aim for,
and I'm pretty convinced at this point that WCAG 2.1 at Level AA is the way
to go: https://www.w3.org/TR/WCAG21/

Why not AAA? Well, it's really hard / time-consuming. For example, users
have to be able to select their own foreground / background colours, if a
user's session expires, they need to be able to login in again and pick off
where they left off (forms filled, etc.), and more. Moreover, every law
I've looked at seems to use WCAG 2.0 (2.1 is just a couple years old and is
backwards compatible) at Level AA, so this seems like the target to aim
for. I don't see a reason to not make specific improvements to AAA where
they're relatively simple, however, but my point is that we should make AA
a minimum requirement.

So if that is accepted, we need a few things:

1. Document it and update the contributing docs.
2. Audit the admin properly.
3. Fix any issues.
4. Make sure reviewers have this in mind for admin changes (I'm not sure if
there's any CI solution for this, but it would be nice to have).

I haven't audited the entire admin, but I have run a checker through some
pages. The main issues are with contrast and small font sizes, and the
changelist also seems quite painful. For example, there are no labels on
the checkboxes to select rows, which is going to be pretty hard to
understand and use if you're blind. A quick aria-label can fix this without
affecting it for sighted users.

Another issue here is harder to solve, it requires two tabs to move to
another row of the change list in the default state (one for the checkbox,
one for the link to the change form page). If you have editable fields in
the change list, it's another tab for each. It would be nice to be able to
use vim keys to move up and down rows, perhaps be able to hit * to select a
row for an action. In general, keyboard shortcuts would be handy elsewhere
too. It would be nice to be able to hit a key to open the nav sidebar which
also sets tab focus on the first link, for example.

But these details aren't the point of the post. The point of the post is to
decide if this is worth it (clearly I think it is), and how to move
forwards on it. Any thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaQhWCtH%2BRZrp8JuXOyPFghAk7GVsJQPD15YHE9DUzQyw%40mail.gmail.com.

Re: Proposal for Table Functions

[Petr Přikryl]

Linking the issue https://code.djangoproject.com/ticket/31609


Dne pondělí 18. května 2020 13:57:49 UTC+2 Ahmad A. Hussein napsal(a):
>
> Concerning tests, I did not mean to comment about the tests you wrote. I 
> used the third party py-test django app as an example of an app that does 
> need work in core to function better, not as a comment about your usage of 
> tests. You're more than free to work the way you want to :) (I like pytest 
> too)
>
> If there's an optimization to be had in including table functions and 
> it'll be backwards compatible without breaking anything, then I think 
> there's merit in the idea. I suggest you open a ticket on the issue tracker 
> and mention how significant the optimization was. It'll help with getting 
> this new feature adopted.
>
> You can open it here 
>
>
>
> On Monday, May 18, 2020 at 8:31:04 AM UTC+2, Petr Přikryl wrote:
>>
>> ad 1. I was testing it on PostgreSQL only. But:
>>
>>- Oracle is feasible through custom extendings in compiler 
>>
>> https://livesql.oracle.com/apex/livesql/file/content_C87XCH8SE085LMS3C5KR03VFS.html
>>- MySQL is also feasible https://stackoverflow.com/a/23421816/1763888
>>- SQLite has some special limited table functions which should be 
>>syntax-compatible with Postgres 
>>https://www.sqlite.org/vtab.html#tabfunc2
>>
>> ad 2. Yes, "it is necessary". Because I must do some nasty hacks in my 
>> gist. For example:
>>
>>- SQL regex parsing 
>>
>> https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a#file-function-py-L189.
>>  
>>Which could be removed if base method would know about parameters.
>>- Classic "Join" overriding 
>>
>> https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a#file-function-py-L277.
>>  
>>I don't like it because I need work with "level" (order) of joins to map 
>> it 
>>to user lookups correctly. If ithis would be in core, then the lookups 
>> from 
>>"filter" could be merged witth lookups from "table_function" more easily. 
>>There is also possibility to merge logic from table_function into filter 
>>and use only filter method for passing parameters into table functions.
>>
>> ad 3. The use case is optimization for me. Because I had SQL View with 
>> recursion. The View was mapped into Django through model. But operations 
>> with this view takes long time for my app. So I found out that I can 
>> optimize that using table function instead view with parameter limiting the 
>> recursion depth. But I couldn't switch view to table function because no 
>> ORM support. With this gist I could.
>>
>> ad tests. I used them because I am used to use them :-). And I think that 
>> it should be re-writable to classic Django tests.
>>
>> Petr
>>
>>
>> Dne neděle 17. května 2020 23:08:08 UTC+2 Ahmad A. Hussein napsal(a):
>>>
>>> I'm not an expert or even an amateur at the ORM, but here are my 
>>> thoughts on the matter:
>>> 1. Does it carry over well across the four databases?
>>> 2. Is it necessary to include it as part of core versus a third-party 
>>> app?
>>> 3. What specific use case will benefit from adopting this idea?
>>>
>>> I ask the second question because it seems from your gist that you don't 
>>> need your proposal to be part of core for it to work. It seems it would 
>>> work completely well and flourish even as a third-party app given how 
>>> you're subclassing the API and expanding on its usage. Contrast this with 
>>> django-pytest for example that can have a harder problem running pytest on 
>>> Django due to how the test runner is currently built (namely that setup 
>>> assumes a subclass of the Django test runner).
>>>
>>> Regards,
>>> Ahmad
>>> On Sun, May 17, 2020 at 4:36 PM Petr Přikryl  wrote:
>>>
 Hi, I have just implemented Table Function support on Django 2.1. What 
 do you think about adopting it into Django itself? 

 https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a

 It is all about passing function parameters into BaseTable and Join 
 classes 
 https://github.com/django/django/blob/master/django/db/models/sql/datastructures.py

 Here are other thoughts which were inspiring me 
 https://schinckel.net/2019/10/31/functions-as-tables-in-django-and-postgres/

 Thanks,
 Petr

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to django-d...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/6d16fdfc-332f-4a72-83ae-04ee5c9fd28a%40googlegroups.com
  
 
 .

>>>

-- 
You 

Re: Clear all filters

[Adam Johnson]

Fran, your design looks nice. I think we should make a ticket that combines
making the "X total" link preserve the query params and adding your other
suggested changes.

On Tue, 19 May 2020 at 08:12, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 18 May 2020, at 11:10, Mariusz Felisiak 
> wrote:
>
> Link to the right of the search box ("X total") already removes the entire
> query string, so ...
>
>
> Ah, this is a bug I'm hitting!
>
> I have a small personal app where I classify data. Some classification is
> automated with regexes. New data needs to be classified manually.
>
> My typical workflow is:
>
> - filter on unclassified data
> - find something interesting
> - use the search field to find all similar data
> - classify it (directly in the list view, thanks to list_editable)
> - clear the search => I lose my filter :-(
> - filter on unclassified data again
> - etc.
>
> Having to set the filter again and again is a minor annoyance so I haven't
> bothered to report a bug. But it's the wrong behavior in this case.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/D962DF7E-2B2F-4D37-9F8C-609ACE4120E9%40polytechnique.org
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0rd5KcJxnU2Y379vX9WUsSSn_MBJXEj6CHPE2yPKSCbw%40mail.gmail.com.

Re: Clear all filters

[Aymeric Augustin]

On 18 May 2020, at 11:10, Mariusz Felisiak  wrote:

> Link to the right of the search box ("X total") already removes the entire 
> query string, so ...


Ah, this is a bug I'm hitting!

I have a small personal app where I classify data. Some classification is 
automated with regexes. New data needs to be classified manually.

My typical workflow is:

- filter on unclassified data
- find something interesting
- use the search field to find all similar data
- classify it (directly in the list view, thanks to list_editable)
- clear the search => I lose my filter :-(
- filter on unclassified data again
- etc.

Having to set the filter again and again is a minor annoyance so I haven't 
bothered to report a bug. But it's the wrong behavior in this case.

Best regards,

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/D962DF7E-2B2F-4D37-9F8C-609ACE4120E9%40polytechnique.org.