Re: Admin accessibility

[Gustavo Sinovsky]

Hi everybody,

I'm very interested in joining this conversation since I believe 
accessibility is an important issue and something often overlooked in 
applications such as the Django admin site. I come in representation of a 
software company called Talpor, located in Santiago de Chile, and we are 
very much interested in helping any way we can to make Django a better 
library. We just posted a ticket 
 with some ideas on how to 
initially tackle this in order to keep the momentum going on this issue, I 
invite you to continue this conversation over there. Also, we actually plan 
to invest some time ourselves in solving some of the issues outlined in the 
ticket, so any specific suggestions are more than welcomed

On Tuesday, May 19, 2020 at 7:12:17 AM UTC-4, Tom Carrick wrote:
>
> 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 v

Re: Admin accessibility

[Andreu Vallbona]

Hi there,

 

I think it's a great initiative, even if as a person with physical 
disabilities, I've never been issues to use any kind of software. 

 

I would be happy to contribute but I'm not aware of any tool that can be 
integrated in any continuous integration system. Whenever I've been working 
in projects that implied accessibility requirements, I've always used 
"manual" processes to verify the web accessibility.

 

Let me know if a team is formed for this purpose. I think I could 
contribute a few hours of work.

 

Personally, I think that, as Adam says, it would be not difficult to amend 
the “low hanging fruits“, such as:

   - 
   
   alt text for images
   - 
   
   semantic use of headings (h1, h2, …)
   - 
   
   avoid use of style tags inside the html code
   - 
   
   lack of contrast in texts
   
 

Web accessibility tools I'm aware of:

   - 
   
   http://colorsafe.co/ - Design accessible color palettes based on WCAG 
   Guidelines 
   - 
   
   https://achecker.ca/checker/index.php  - Web Accessibility Checker
   - 
   
   http://www.niquelao.net/wcag_contrast_checker/ - color contrast checker
   - 
   
   http://webaim.org/resources/contrastchecker/ - color contrast checker
   - 
   
   http://www.visionaustralia.org.au/info.aspx?page=1812 - Correct use of 
   tables
   
Kind regards



El dimarts, 19 maig de 2020 13:12:17 UTC+2, Tom Carrick va escriure:
>
> 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 th

timesince 'depth' parameter

[Toby Such]

Hi all!

I've been a little frustrated with the timesince filter that comes with 
default Django. By default it always comes with 2 parts e.g. 4 hours and 3 
minutes ago but I would much rather have just the 4 hours. In my own 
projects I've simply created my own version of the timesince filter and 
accompanying 
utils function that powers it that just has the code which adds the second 
part removed. However I wonder why this isn't standard as I can't think of 
a single website that displays time since as multiple parts. 

I'm proposing adding a 'depth' parameter to the timesince function which 
would allow the developer to set how many parts to render. At depth one it 
would be "3 weeks". 2 depth: "3 weeks 2 days" (default behaviour), 3 depth: 
"3 weeks, 2 days, 4 hours ago" etc.

Does anyone have any thoughts related to this?

-- 
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/97fbcab8-3f0f-4277-9296-fdcff7fcdab5%40googlegroups.com.

Re: timesince 'depth' parameter

[אורי]

Hi,

On Sat, May 23, 2020 at 12:39 AM Toby Such  wrote:

> Hi all!
>
> I've been a little frustrated with the timesince filter that comes with
> default Django. By default it always comes with 2 parts e.g. 4 hours and 3
> minutes ago but I would much rather have just the 4 hours. In my own
> projects I've simply created my own version of the timesince filter and 
> accompanying
> utils function that powers it that just has the code which adds the second
> part removed. However I wonder why this isn't standard as I can't think of
> a single website that displays time since as multiple parts.
>
> I'm proposing adding a 'depth' parameter to the timesince function which
> would allow the developer to set how many parts to render. At depth one it
> would be "3 weeks". 2 depth: "3 weeks 2 days" (default behaviour), 3 depth:
> "3 weeks, 2 days, 4 hours ago" etc.
>
>
Actually I think it's a good idea. I don't think I ever used this feature
with Django, but it's nice to have anyway.

Have you seen this question from 2011?
https://stackoverflow.com/questions/6481788/format-of-timesince-filter

Also, other related questions from
https://www.google.com/search?q=timesince+filter

אורי

-- 
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/CABD5YeGU2_2Bj2F%3DPW-KZVCg-2jSr1TVi9gi%3DWD3MZgjK50syw%40mail.gmail.com.

Re: timesince 'depth' parameter

[Toby Such]

Looks like other people seemed to have the same idea as me for a little 
fix, seems to me like it should be part of core Django. And yes I do admit 
its a small thing but if it was actually useful some more people might use 
it? 

On Friday, 22 May 2020 23:21:16 UTC+1, Uri wrote:
>
> Hi,
>
> On Sat, May 23, 2020 at 12:39 AM Toby Such  > wrote:
>
>> Hi all!
>>
>> I've been a little frustrated with the timesince filter that comes with 
>> default Django. By default it always comes with 2 parts e.g. 4 hours and 3 
>> minutes ago but I would much rather have just the 4 hours. In my own 
>> projects I've simply created my own version of the timesince filter and 
>> accompanying 
>> utils function that powers it that just has the code which adds the second 
>> part removed. However I wonder why this isn't standard as I can't think of 
>> a single website that displays time since as multiple parts. 
>>
>> I'm proposing adding a 'depth' parameter to the timesince function which 
>> would allow the developer to set how many parts to render. At depth one it 
>> would be "3 weeks". 2 depth: "3 weeks 2 days" (default behaviour), 3 depth: 
>> "3 weeks, 2 days, 4 hours ago" etc.
>>
>>
> Actually I think it's a good idea. I don't think I ever used this feature 
> with Django, but it's nice to have anyway.
>
> Have you seen this question from 2011?
> https://stackoverflow.com/questions/6481788/format-of-timesince-filter 
>
> Also, other related questions from 
> https://www.google.com/search?q=timesince+filter 
>
> אורי
>

-- 
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/75977497-708d-4292-bdce-ea29ec668f65%40googlegroups.com.