Re: Admin accessibility

[Carlton Gibson]

Hey Thibaud. 

Thanks for this, yes! 

On the team: I'm going to take the response here as approval and move that 
forward. Just haven't got to it yet. 

On the issues: All good, except I don't think we can actually remove as_p() 
and co. I think we'll have to go the Aria route. I haven't yet moved those 
tickets forward as I've been occupied with the v3.2 feature freeze. 

It's really good to have someone on board thinking about these issues! 
Thanks again. 

Kind Regards,

Carlton


On Thursday, 14 January 2021 at 02:10:31 UTC+1 Thibaud Colas wrote:

> Hi all,
>
> I know setting up the team is still under way but in the meantime I wanted 
> to bring your attention to a set of issues I recently reported about the 
> accessibility of Django forms:
>
> - The as_table, as_ul, as_p output styles being inappropriate, 
> https://code.djangoproject.com/ticket/32338
> - Markup issues with fields based on multiple radio or checkbox, 
> https://code.djangoproject.com/ticket/32339
> - Usability concerns with text fields that expect specific formatting, 
> https://code.djangoproject.com/ticket/32340
>
> Those issues are what I’ve come across the most while working on Django 
> sites, and I think are by far what end users are most likely to run into. 
> So I thought it would be worthwhile to report the problems sooner rather 
> than later, and share it here for others’ consideration. I’d also 
> appreciate on what makes for a good issue report for accessibility in 
> particular if anyone has feedback on that area – I was quite keen to make 
> more screen recordings but the ticket tracker only supports very small 
> images and video seemed a bit overkill. But am happy to upload bug reports 
> to YouTube if others would value this.
>
> Best regards,
>
> Thibaud
>
> On Thursday, 12 November 2020 at 09:24:22 UTC carlton...@gmail.com wrote:
>
>> Thanks all — I think we're there. 
>>
>> All positives expressed. Do I need to ensure those who've not 
>> commented/voted do so? 
>>
>>
>> One question while we're here: 
>>
>> * Do we have any specialist designers on board who could help serve on 
>> this team? 
>> * Related who can I ping ref the design on djangoproject.com? (Who did 
>> the design work do we recall? — there are credits at the bottom of the 
>> website, but I'm wondering if someone can point me straight to the 
>> responsible people?)
>>
>> Why? Read on... 
>>
>> So we have this PR on to fix the color contrasts on the main website: 
>> https://github.com/django/djangoproject.com/pull/998
>>
>> All good, but there's some question about the color palette in use. 
>> (There are several shades of green, we need to adjust some, and it appears 
>> the Official™ shade isn't actually in use, so...) 
>> Having a specialist designer on board would enable that discussion to go 
>> much more quickly and securely down the Happy Path there, without the risk 
>> of death-by-a-thousand-cuts to the whole aesthetic. 
>> This would be a big value-add to have available, without I think being a 
>> big time commitment for the folks involved. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Monday, 2 November 2020 at 12:51:23 UTC+1 James Bennett wrote:
>>
>>> Taking this as a question posed under the DEP 10 voting process of 
>>> whether or not to accept DEP 11:
>>>
>>> I vote +1.
>>>
>>> I think the basic idea is good; there are a couple things worth 
>>> clarifying, mostly in terms of oversight, but that can be addressed in 
>>> later edits.
>>>
>>> And by "oversight" I mean a clear statement of how members of the team 
>>> are to be chosen, who will do the choosing, and whether the ultimate 
>>> responsibility lies with the Django Technical Board or with the DSF Board 
>>> of Directors. Since the scope of the DEP includes things that the Technical 
>>> Board lacks authority over, it may need to be the DSF Board or a mix of 
>>> both; also, the DSF Board would need to formally accept that responsibility.
>>>
>>>
>>> On Thu, Oct 29, 2020 at 4:01 AM Carlton Gibson  
>>> wrote:
>>>
 Hello all. 

 Can I ask the Technical Board for Review and Resolution 
 
  
 on DEP 11 please? 

 https://github.com/django/deps/pull/69/

 (Please let me know if I've done that wrong.) 

 Kind regards, 
 Carlton

 On Thursday, 22 October 2020 at 10:43:03 UTC+2 Carlton Gibson wrote:

> Hi all. 
>
> The DEP for creating an accessibility team is looking good. 
> https://github.com/django/deps/pull/69
>
> I'm going to ask for formal consideration shortly. 
> If you have an interest/a moment, over the weekend say, to give it a 
> glance before that, then any comments will be gratefully received I'm 
> sure. 
>
> Thanks. 
>
> Kind Regards,
>
> Carlton
>
>
> On Wednesday, 16 September 2020 at 00:17:35 UTC+2 Thibaud Colas wrote:
>
>> 

Re: Admin accessibility

[Thibaud Colas]

Hi all,

I know setting up the team is still under way but in the meantime I wanted 
to bring your attention to a set of issues I recently reported about the 
accessibility of Django forms:

- The as_table, as_ul, as_p output styles being inappropriate, 
https://code.djangoproject.com/ticket/32338
- Markup issues with fields based on multiple radio or checkbox, 
https://code.djangoproject.com/ticket/32339
- Usability concerns with text fields that expect specific formatting, 
https://code.djangoproject.com/ticket/32340

Those issues are what I’ve come across the most while working on Django 
sites, and I think are by far what end users are most likely to run into. 
So I thought it would be worthwhile to report the problems sooner rather 
than later, and share it here for others’ consideration. I’d also 
appreciate on what makes for a good issue report for accessibility in 
particular if anyone has feedback on that area – I was quite keen to make 
more screen recordings but the ticket tracker only supports very small 
images and video seemed a bit overkill. But am happy to upload bug reports 
to YouTube if others would value this.

Best regards,

Thibaud

On Thursday, 12 November 2020 at 09:24:22 UTC carlton...@gmail.com wrote:

> Thanks all — I think we're there. 
>
> All positives expressed. Do I need to ensure those who've not 
> commented/voted do so? 
>
>
> One question while we're here: 
>
> * Do we have any specialist designers on board who could help serve on 
> this team? 
> * Related who can I ping ref the design on djangoproject.com? (Who did 
> the design work do we recall? — there are credits at the bottom of the 
> website, but I'm wondering if someone can point me straight to the 
> responsible people?)
>
> Why? Read on... 
>
> So we have this PR on to fix the color contrasts on the main website: 
> https://github.com/django/djangoproject.com/pull/998
>
> All good, but there's some question about the color palette in use. (There 
> are several shades of green, we need to adjust some, and it appears the 
> Official™ shade isn't actually in use, so...) 
> Having a specialist designer on board would enable that discussion to go 
> much more quickly and securely down the Happy Path there, without the risk 
> of death-by-a-thousand-cuts to the whole aesthetic. 
> This would be a big value-add to have available, without I think being a 
> big time commitment for the folks involved. 
>
> Kind Regards,
>
> Carlton
>
>
> On Monday, 2 November 2020 at 12:51:23 UTC+1 James Bennett wrote:
>
>> Taking this as a question posed under the DEP 10 voting process of 
>> whether or not to accept DEP 11:
>>
>> I vote +1.
>>
>> I think the basic idea is good; there are a couple things worth 
>> clarifying, mostly in terms of oversight, but that can be addressed in 
>> later edits.
>>
>> And by "oversight" I mean a clear statement of how members of the team 
>> are to be chosen, who will do the choosing, and whether the ultimate 
>> responsibility lies with the Django Technical Board or with the DSF Board 
>> of Directors. Since the scope of the DEP includes things that the Technical 
>> Board lacks authority over, it may need to be the DSF Board or a mix of 
>> both; also, the DSF Board would need to formally accept that responsibility.
>>
>>
>> On Thu, Oct 29, 2020 at 4:01 AM Carlton Gibson  
>> wrote:
>>
>>> Hello all. 
>>>
>>> Can I ask the Technical Board for Review and Resolution 
>>> 
>>>  
>>> on DEP 11 please? 
>>>
>>> https://github.com/django/deps/pull/69/
>>>
>>> (Please let me know if I've done that wrong.) 
>>>
>>> Kind regards, 
>>> Carlton
>>>
>>> On Thursday, 22 October 2020 at 10:43:03 UTC+2 Carlton Gibson wrote:
>>>
 Hi all. 

 The DEP for creating an accessibility team is looking good. 
 https://github.com/django/deps/pull/69

 I'm going to ask for formal consideration shortly. 
 If you have an interest/a moment, over the weekend say, to give it a 
 glance before that, then any comments will be gratefully received I'm 
 sure. 

 Thanks. 

 Kind Regards,

 Carlton


 On Wednesday, 16 September 2020 at 00:17:35 UTC+2 Thibaud Colas wrote:

> I’d love to! But worth bearing in mind that I haven’t done any Django 
> contributions before.
>
> I decided to end my talk with a call for feedback on your DEP – this 
> feels like the ideal call to action to end on.
>
> On Monday, 14 September 2020 at 18:00:03 UTC+1 t...@carrick.eu wrote:
>
>> Carlton, I think that would be useful, thanks.
>>
>> Thibaud, shall I add you to the implementation team? It seems like 
>> you're doing more work on this than I am lately. I think we could still 
>> use 
>> one or perhaps two more people, but I think it's a good start.
>>
>> On Mon, 14 Sep 2020 at 16:44, Carlton Gibson  
>> wrote:
>>

Re: Admin accessibility

[Carlton Gibson]

Thanks all — I think we're there. 

All positives expressed. Do I need to ensure those who've not 
commented/voted do so? 


One question while we're here: 

* Do we have any specialist designers on board who could help serve on this 
team? 
* Related who can I ping ref the design on djangoproject.com? (Who did the 
design work do we recall? — there are credits at the bottom of the website, 
but I'm wondering if someone can point me straight to the responsible 
people?)

Why? Read on... 

So we have this PR on to fix the color contrasts on the main website: 
https://github.com/django/djangoproject.com/pull/998

All good, but there's some question about the color palette in use. (There 
are several shades of green, we need to adjust some, and it appears the 
Official™ shade isn't actually in use, so...) 
Having a specialist designer on board would enable that discussion to go 
much more quickly and securely down the Happy Path there, without the risk 
of death-by-a-thousand-cuts to the whole aesthetic. 
This would be a big value-add to have available, without I think being a 
big time commitment for the folks involved. 

Kind Regards,

Carlton


On Monday, 2 November 2020 at 12:51:23 UTC+1 James Bennett wrote:

> Taking this as a question posed under the DEP 10 voting process of whether 
> or not to accept DEP 11:
>
> I vote +1.
>
> I think the basic idea is good; there are a couple things worth 
> clarifying, mostly in terms of oversight, but that can be addressed in 
> later edits.
>
> And by "oversight" I mean a clear statement of how members of the team are 
> to be chosen, who will do the choosing, and whether the ultimate 
> responsibility lies with the Django Technical Board or with the DSF Board 
> of Directors. Since the scope of the DEP includes things that the Technical 
> Board lacks authority over, it may need to be the DSF Board or a mix of 
> both; also, the DSF Board would need to formally accept that responsibility.
>
>
> On Thu, Oct 29, 2020 at 4:01 AM Carlton Gibson  
> wrote:
>
>> Hello all. 
>>
>> Can I ask the Technical Board for Review and Resolution 
>> 
>>  
>> on DEP 11 please? 
>>
>> https://github.com/django/deps/pull/69/
>>
>> (Please let me know if I've done that wrong.) 
>>
>> Kind regards, 
>> Carlton
>>
>> On Thursday, 22 October 2020 at 10:43:03 UTC+2 Carlton Gibson wrote:
>>
>>> Hi all. 
>>>
>>> The DEP for creating an accessibility team is looking good. 
>>> https://github.com/django/deps/pull/69
>>>
>>> I'm going to ask for formal consideration shortly. 
>>> If you have an interest/a moment, over the weekend say, to give it a 
>>> glance before that, then any comments will be gratefully received I'm sure. 
>>>
>>> Thanks. 
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> On Wednesday, 16 September 2020 at 00:17:35 UTC+2 Thibaud Colas wrote:
>>>
 I’d love to! But worth bearing in mind that I haven’t done any Django 
 contributions before.

 I decided to end my talk with a call for feedback on your DEP – this 
 feels like the ideal call to action to end on.

 On Monday, 14 September 2020 at 18:00:03 UTC+1 t...@carrick.eu wrote:

> Carlton, I think that would be useful, thanks.
>
> Thibaud, shall I add you to the implementation team? It seems like 
> you're doing more work on this than I am lately. I think we could still 
> use 
> one or perhaps two more people, but I think it's a good start.
>
> On Mon, 14 Sep 2020 at 16:44, Carlton Gibson  
> wrote:
>
>> Hi All. 
>>
>> Thanks for this. I'd be happy to play *Shepherd *if you need someone 
>> to put their hand up. 
>> I think that means I need to nag about getting it done. So... 
>>
>> Who's going to be on the team to do the first review, and then 
>> subsequent work? Answer that and you have the Implementation Team. 
>> I like that you've thought about how the team can refresh 
>> periodically — I don't suppose the burden will be too great but folks 
>> tend 
>> to cycle-out naturally, so good to plan for that. 
>> Thibaud: Asking for hands in your talk seems sensible. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>>
>>> Hi all,
>>>
>>> Now that the DEP PR has been submitted I was wondering what the next 
>>> steps would be. According to the documented DEP process I found, it’s 
>>> at 
>>> the "forming the team" 
>>> 
>>>  
>>> stage? How do you go about creating an *Implementation Team* and 
>>> finding a *Shepherd*?
>>>
>>> The main reason I ask is that I’ll be giving a talk about 
>>> accessibility at DjangoCon EU in a couple of weeks, and I thought it 
>>> would 

Re: Admin accessibility

[James Bennett]

Taking this as a question posed under the DEP 10 voting process of whether
or not to accept DEP 11:

I vote +1.

I think the basic idea is good; there are a couple things worth clarifying,
mostly in terms of oversight, but that can be addressed in later edits.

And by "oversight" I mean a clear statement of how members of the team are
to be chosen, who will do the choosing, and whether the ultimate
responsibility lies with the Django Technical Board or with the DSF Board
of Directors. Since the scope of the DEP includes things that the Technical
Board lacks authority over, it may need to be the DSF Board or a mix of
both; also, the DSF Board would need to formally accept that responsibility.


On Thu, Oct 29, 2020 at 4:01 AM Carlton Gibson 
wrote:

> Hello all.
>
> Can I ask the Technical Board for Review and Resolution
> 
> on DEP 11 please?
>
> https://github.com/django/deps/pull/69/
>
> (Please let me know if I've done that wrong.)
>
> Kind regards,
> Carlton
>
> On Thursday, 22 October 2020 at 10:43:03 UTC+2 Carlton Gibson wrote:
>
>> Hi all.
>>
>> The DEP for creating an accessibility team is looking good.
>> https://github.com/django/deps/pull/69
>>
>> I'm going to ask for formal consideration shortly.
>> If you have an interest/a moment, over the weekend say, to give it a
>> glance before that, then any comments will be gratefully received I'm sure.
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Wednesday, 16 September 2020 at 00:17:35 UTC+2 Thibaud Colas wrote:
>>
>>> I’d love to! But worth bearing in mind that I haven’t done any Django
>>> contributions before.
>>>
>>> I decided to end my talk with a call for feedback on your DEP – this
>>> feels like the ideal call to action to end on.
>>>
>>> On Monday, 14 September 2020 at 18:00:03 UTC+1 t...@carrick.eu wrote:
>>>
 Carlton, I think that would be useful, thanks.

 Thibaud, shall I add you to the implementation team? It seems like
 you're doing more work on this than I am lately. I think we could still use
 one or perhaps two more people, but I think it's a good start.

 On Mon, 14 Sep 2020 at 16:44, Carlton Gibson 
 wrote:

> Hi All.
>
> Thanks for this. I'd be happy to play *Shepherd *if you need someone
> to put their hand up.
> I think that means I need to nag about getting it done. So... 
>
> Who's going to be on the team to do the first review, and then
> subsequent work? Answer that and you have the Implementation Team.
> I like that you've thought about how the team can refresh periodically
> — I don't suppose the burden will be too great but folks tend to cycle-out
> naturally, so good to plan for that.
> Thibaud: Asking for hands in your talk seems sensible.
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>
>> Hi all,
>>
>> Now that the DEP PR has been submitted I was wondering what the next
>> steps would be. According to the documented DEP process I found, it’s at
>> the "forming the team"
>> 
>> stage? How do you go about creating an *Implementation Team* and
>> finding a *Shepherd*?
>>
>> The main reason I ask is that I’ll be giving a talk about
>> accessibility at DjangoCon EU in a couple of weeks, and I thought it 
>> would
>> be a good occasion to raise awareness of the issues with the Django 
>> admin,
>> and mention this DEP. But I want to make sure I provide accurate
>> information.
>>
>> Thanks in advance,
>>
>> Thibaud
>>
>> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>>
>>>  it’s wonderful to see this happening! Re-reading through the
>>> whole thing, as Tobias mentioned I also find it very easy to read, and
>>> makes a good case.
>>>
>>> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>>>
 I've added a PR to the DEPs repo to hopefully get some eyes on it:
 https://github.com/django/deps/pull/69

 Thibaud, I think whatever you have the time and motivation for
 sounds good, all of those things are useful. If you're not sure about 
 all
 the admin features, I think that's pretty normal. One project I've had 
 on
 my mind for a while now is to build a simple django site that is
 essentially just there to use every feature of the admin, so I might 
 bump
 that up the priority list, though it's somewhat daunting.

 Cheers,
 Tom

 On Mon, 13 Jul 2020 at 01:15, Thibaud Colas 
 wrote:

> Update for the proof of concept CI tests from my side – thank you

Re: Admin accessibility

[Adam Johnson]

I've made a few comments on the PR requesting clarification, but I see this
as a big win. Comparing it to the "minimum criteria for a DEP"...

It must be a clear and complete description of the proposed enhancement.
>

The only lack of clarity I see is around who's a member, and how renewing
membership works.


> The enhancement must represent a net improvement.
>

Definitely! This also won't just affect disabled people - I liked the
citation of Alex Chan on the curb cut effect.


> The proposed implementation, if applicable, must be solid and must not
> complicate Django unduly.
>

Accessibility changes may add some complexity, but this will be far from
"undue". They'll even be a legal requirement for many users.


> Finally, a proposed enhancement must "fit" with Django's general
> philosophy and architecture
>

A clear fit. We want to support diversity both inside the DSF and on the
web.

On Thu, 29 Oct 2020 at 11:01, Carlton Gibson 
wrote:

> Hello all.
>
> Can I ask the Technical Board for Review and Resolution
> 
> on DEP 11 please?
>
> https://github.com/django/deps/pull/69/
>
> (Please let me know if I've done that wrong.)
>
> Kind regards,
> Carlton
>
> On Thursday, 22 October 2020 at 10:43:03 UTC+2 Carlton Gibson wrote:
>
>> Hi all.
>>
>> The DEP for creating an accessibility team is looking good.
>> https://github.com/django/deps/pull/69
>>
>> I'm going to ask for formal consideration shortly.
>> If you have an interest/a moment, over the weekend say, to give it a
>> glance before that, then any comments will be gratefully received I'm sure.
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Wednesday, 16 September 2020 at 00:17:35 UTC+2 Thibaud Colas wrote:
>>
>>> I’d love to! But worth bearing in mind that I haven’t done any Django
>>> contributions before.
>>>
>>> I decided to end my talk with a call for feedback on your DEP – this
>>> feels like the ideal call to action to end on.
>>>
>>> On Monday, 14 September 2020 at 18:00:03 UTC+1 t...@carrick.eu wrote:
>>>
 Carlton, I think that would be useful, thanks.

 Thibaud, shall I add you to the implementation team? It seems like
 you're doing more work on this than I am lately. I think we could still use
 one or perhaps two more people, but I think it's a good start.

 On Mon, 14 Sep 2020 at 16:44, Carlton Gibson 
 wrote:

> Hi All.
>
> Thanks for this. I'd be happy to play *Shepherd *if you need someone
> to put their hand up.
> I think that means I need to nag about getting it done. So... 
>
> Who's going to be on the team to do the first review, and then
> subsequent work? Answer that and you have the Implementation Team.
> I like that you've thought about how the team can refresh periodically
> — I don't suppose the burden will be too great but folks tend to cycle-out
> naturally, so good to plan for that.
> Thibaud: Asking for hands in your talk seems sensible.
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>
>> Hi all,
>>
>> Now that the DEP PR has been submitted I was wondering what the next
>> steps would be. According to the documented DEP process I found, it’s at
>> the "forming the team"
>> 
>> stage? How do you go about creating an *Implementation Team* and
>> finding a *Shepherd*?
>>
>> The main reason I ask is that I’ll be giving a talk about
>> accessibility at DjangoCon EU in a couple of weeks, and I thought it 
>> would
>> be a good occasion to raise awareness of the issues with the Django 
>> admin,
>> and mention this DEP. But I want to make sure I provide accurate
>> information.
>>
>> Thanks in advance,
>>
>> Thibaud
>>
>> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>>
>>>  it’s wonderful to see this happening! Re-reading through the
>>> whole thing, as Tobias mentioned I also find it very easy to read, and
>>> makes a good case.
>>>
>>> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>>>
 I've added a PR to the DEPs repo to hopefully get some eyes on it:
 https://github.com/django/deps/pull/69

 Thibaud, I think whatever you have the time and motivation for
 sounds good, all of those things are useful. If you're not sure about 
 all
 the admin features, I think that's pretty normal. One project I've had 
 on
 my mind for a while now is to build a simple django site that is
 essentially just there to use every feature of the admin, so I might 
 bump
 that up the priority list, though it's somewhat daunting.

Re: Admin accessibility

[Carlton Gibson]

Hello all. 

Can I ask the Technical Board for Review and Resolution 

 
on DEP 11 please? 

https://github.com/django/deps/pull/69/

(Please let me know if I've done that wrong.) 

Kind regards, 
Carlton

On Thursday, 22 October 2020 at 10:43:03 UTC+2 Carlton Gibson wrote:

> Hi all. 
>
> The DEP for creating an accessibility team is looking good. 
> https://github.com/django/deps/pull/69
>
> I'm going to ask for formal consideration shortly. 
> If you have an interest/a moment, over the weekend say, to give it a 
> glance before that, then any comments will be gratefully received I'm sure. 
>
> Thanks. 
>
> Kind Regards,
>
> Carlton
>
>
> On Wednesday, 16 September 2020 at 00:17:35 UTC+2 Thibaud Colas wrote:
>
>> I’d love to! But worth bearing in mind that I haven’t done any Django 
>> contributions before.
>>
>> I decided to end my talk with a call for feedback on your DEP – this 
>> feels like the ideal call to action to end on.
>>
>> On Monday, 14 September 2020 at 18:00:03 UTC+1 t...@carrick.eu wrote:
>>
>>> Carlton, I think that would be useful, thanks.
>>>
>>> Thibaud, shall I add you to the implementation team? It seems like 
>>> you're doing more work on this than I am lately. I think we could still use 
>>> one or perhaps two more people, but I think it's a good start.
>>>
>>> On Mon, 14 Sep 2020 at 16:44, Carlton Gibson  
>>> wrote:
>>>
 Hi All. 

 Thanks for this. I'd be happy to play *Shepherd *if you need someone 
 to put their hand up. 
 I think that means I need to nag about getting it done. So... 

 Who's going to be on the team to do the first review, and then 
 subsequent work? Answer that and you have the Implementation Team. 
 I like that you've thought about how the team can refresh periodically 
 — I don't suppose the burden will be too great but folks tend to cycle-out 
 naturally, so good to plan for that. 
 Thibaud: Asking for hands in your talk seems sensible. 

 Kind Regards,

 Carlton



 On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:

> Hi all,
>
> Now that the DEP PR has been submitted I was wondering what the next 
> steps would be. According to the documented DEP process I found, it’s at 
> the "forming the team" 
> 
>  
> stage? How do you go about creating an *Implementation Team* and 
> finding a *Shepherd*?
>
> The main reason I ask is that I’ll be giving a talk about 
> accessibility at DjangoCon EU in a couple of weeks, and I thought it 
> would 
> be a good occasion to raise awareness of the issues with the Django 
> admin, 
> and mention this DEP. But I want to make sure I provide accurate 
> information.
>
> Thanks in advance,
>
> Thibaud
>
> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>
>>  it’s wonderful to see this happening! Re-reading through the whole 
>> thing, as Tobias mentioned I also find it very easy to read, and makes a 
>> good case.
>>
>> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>>
>>> I've added a PR to the DEPs repo to hopefully get some eyes on it: 
>>> https://github.com/django/deps/pull/69
>>>
>>> Thibaud, I think whatever you have the time and motivation for 
>>> sounds good, all of those things are useful. If you're not sure about 
>>> all 
>>> the admin features, I think that's pretty normal. One project I've had 
>>> on 
>>> my mind for a while now is to build a simple django site that is 
>>> essentially just there to use every feature of the admin, so I might 
>>> bump 
>>> that up the priority list, though it's somewhat daunting.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  
>>> wrote:
>>>
 Update for the proof of concept CI tests from my side – thank you 
 Tom for the feedback. Here are the latest additions to the test suite 
 & 
 reports, still living at 
 https://thibaudcolas.github.io/django_admin_tests/,

 - Added as much as I know about in the admin, and now also outside 
 of it a bit (startproject welcome page, error pages)
 - Separated the issues between Axe and HTML_CS so the numbers are 
 easier to understand
 - Added anchor links everywhere for easier navigation
 - I’ve also started a draft list of "things to (potentially) 
 audit", over at 
 https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits

 I think the next two big steps are what you mention:

 - Having a way to track the number of issues over time. Currently 

Re: Admin accessibility

[Carlton Gibson]

Hi all. 

The DEP for creating an accessibility team is looking good. 
https://github.com/django/deps/pull/69

I'm going to ask for formal consideration shortly. 
If you have an interest/a moment, over the weekend say, to give it a glance 
before that, then any comments will be gratefully received I'm sure. 

Thanks. 

Kind Regards,

Carlton


On Wednesday, 16 September 2020 at 00:17:35 UTC+2 Thibaud Colas wrote:

> I’d love to! But worth bearing in mind that I haven’t done any Django 
> contributions before.
>
> I decided to end my talk with a call for feedback on your DEP – this feels 
> like the ideal call to action to end on.
>
> On Monday, 14 September 2020 at 18:00:03 UTC+1 t...@carrick.eu wrote:
>
>> Carlton, I think that would be useful, thanks.
>>
>> Thibaud, shall I add you to the implementation team? It seems like you're 
>> doing more work on this than I am lately. I think we could still use one or 
>> perhaps two more people, but I think it's a good start.
>>
>> On Mon, 14 Sep 2020 at 16:44, Carlton Gibson  
>> wrote:
>>
>>> Hi All. 
>>>
>>> Thanks for this. I'd be happy to play *Shepherd *if you need someone to 
>>> put their hand up. 
>>> I think that means I need to nag about getting it done. So... 
>>>
>>> Who's going to be on the team to do the first review, and then 
>>> subsequent work? Answer that and you have the Implementation Team. 
>>> I like that you've thought about how the team can refresh periodically — 
>>> I don't suppose the burden will be too great but folks tend to cycle-out 
>>> naturally, so good to plan for that. 
>>> Thibaud: Asking for hands in your talk seems sensible. 
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>>
>>> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>>>
 Hi all,

 Now that the DEP PR has been submitted I was wondering what the next 
 steps would be. According to the documented DEP process I found, it’s at 
 the "forming the team" 
 
  
 stage? How do you go about creating an *Implementation Team* and 
 finding a *Shepherd*?

 The main reason I ask is that I’ll be giving a talk about accessibility 
 at DjangoCon EU in a couple of weeks, and I thought it would be a good 
 occasion to raise awareness of the issues with the Django admin, and 
 mention this DEP. But I want to make sure I provide accurate information.

 Thanks in advance,

 Thibaud

 On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:

>  it’s wonderful to see this happening! Re-reading through the whole 
> thing, as Tobias mentioned I also find it very easy to read, and makes a 
> good case.
>
> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>
>> I've added a PR to the DEPs repo to hopefully get some eyes on it: 
>> https://github.com/django/deps/pull/69
>>
>> Thibaud, I think whatever you have the time and motivation for sounds 
>> good, all of those things are useful. If you're not sure about all the 
>> admin features, I think that's pretty normal. One project I've had on my 
>> mind for a while now is to build a simple django site that is 
>> essentially 
>> just there to use every feature of the admin, so I might bump that up 
>> the 
>> priority list, though it's somewhat daunting.
>>
>> Cheers,
>> Tom
>>
>> On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  
>> wrote:
>>
>>> Update for the proof of concept CI tests from my side – thank you 
>>> Tom for the feedback. Here are the latest additions to the test suite & 
>>> reports, still living at 
>>> https://thibaudcolas.github.io/django_admin_tests/,
>>>
>>> - Added as much as I know about in the admin, and now also outside 
>>> of it a bit (startproject welcome page, error pages)
>>> - Separated the issues between Axe and HTML_CS so the numbers are 
>>> easier to understand
>>> - Added anchor links everywhere for easier navigation
>>> - I’ve also started a draft list of "things to (potentially) audit", 
>>> over at 
>>> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>>>
>>> I think the next two big steps are what you mention:
>>>
>>> - Having a way to track the number of issues over time. Currently 
>>> the report overwrites itself every week (well, every build). If you 
>>> have a 
>>> suggestion on ways to demo this that would be useful please let me 
>>> know. 
>>> Currently I’m thinking sparklines for each test case could be nice as a 
>>> proof of concept, and a sparkline for the total number of issues. Or 
>>> see 
>>> whether I should get out of my comfort zone a bit and find a 
>>> dashboard/graphing tool to send the metrics to and graph there.
>>> - Testing more features of 

Re: Admin accessibility

[Thibaud Colas]

I’d love to! But worth bearing in mind that I haven’t done any Django 
contributions before.

I decided to end my talk with a call for feedback on your DEP – this feels 
like the ideal call to action to end on.

On Monday, 14 September 2020 at 18:00:03 UTC+1 t...@carrick.eu wrote:

> Carlton, I think that would be useful, thanks.
>
> Thibaud, shall I add you to the implementation team? It seems like you're 
> doing more work on this than I am lately. I think we could still use one or 
> perhaps two more people, but I think it's a good start.
>
> On Mon, 14 Sep 2020 at 16:44, Carlton Gibson  wrote:
>
>> Hi All. 
>>
>> Thanks for this. I'd be happy to play *Shepherd *if you need someone to 
>> put their hand up. 
>> I think that means I need to nag about getting it done. So... 
>>
>> Who's going to be on the team to do the first review, and then subsequent 
>> work? Answer that and you have the Implementation Team. 
>> I like that you've thought about how the team can refresh periodically — 
>> I don't suppose the burden will be too great but folks tend to cycle-out 
>> naturally, so good to plan for that. 
>> Thibaud: Asking for hands in your talk seems sensible. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>>
>>> Hi all,
>>>
>>> Now that the DEP PR has been submitted I was wondering what the next 
>>> steps would be. According to the documented DEP process I found, it’s at 
>>> the "forming the team" 
>>> 
>>>  
>>> stage? How do you go about creating an *Implementation Team* and 
>>> finding a *Shepherd*?
>>>
>>> The main reason I ask is that I’ll be giving a talk about accessibility 
>>> at DjangoCon EU in a couple of weeks, and I thought it would be a good 
>>> occasion to raise awareness of the issues with the Django admin, and 
>>> mention this DEP. But I want to make sure I provide accurate information.
>>>
>>> Thanks in advance,
>>>
>>> Thibaud
>>>
>>> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>>>
  it’s wonderful to see this happening! Re-reading through the whole 
 thing, as Tobias mentioned I also find it very easy to read, and makes a 
 good case.

 On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:

> I've added a PR to the DEPs repo to hopefully get some eyes on it: 
> https://github.com/django/deps/pull/69
>
> Thibaud, I think whatever you have the time and motivation for sounds 
> good, all of those things are useful. If you're not sure about all the 
> admin features, I think that's pretty normal. One project I've had on my 
> mind for a while now is to build a simple django site that is essentially 
> just there to use every feature of the admin, so I might bump that up the 
> priority list, though it's somewhat daunting.
>
> Cheers,
> Tom
>
> On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  
> wrote:
>
>> Update for the proof of concept CI tests from my side – thank you Tom 
>> for the feedback. Here are the latest additions to the test suite & 
>> reports, still living at 
>> https://thibaudcolas.github.io/django_admin_tests/,
>>
>> - Added as much as I know about in the admin, and now also outside of 
>> it a bit (startproject welcome page, error pages)
>> - Separated the issues between Axe and HTML_CS so the numbers are 
>> easier to understand
>> - Added anchor links everywhere for easier navigation
>> - I’ve also started a draft list of "things to (potentially) audit", 
>> over at 
>> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>>
>> I think the next two big steps are what you mention:
>>
>> - Having a way to track the number of issues over time. Currently the 
>> report overwrites itself every week (well, every build). If you have a 
>> suggestion on ways to demo this that would be useful please let me know. 
>> Currently I’m thinking sparklines for each test case could be nice as a 
>> proof of concept, and a sparkline for the total number of issues. Or see 
>> whether I should get out of my comfort zone a bit and find a 
>> dashboard/graphing tool to send the metrics to and graph there.
>> - Testing more features of modeladmin. I don’t use it too frequently 
>> myself so don’t really know what’s “easy” to enable – if you know of an 
>> existing test suite I could repurpose, or of an example of using a lot 
>> of 
>> functionality – I’d be keen to invest time to add it to my test site.
>>
>> Alternatively something else I could do is to file a ticket for 
>> accessibility issues with the welcome page – I’ve tested it with screen 
>> readers, there are a few issues, but nothing that should be too hard to 
>> fix, and it might be a good demo of 

Re: Admin accessibility

[Tom Carrick]

Carlton, I think that would be useful, thanks.

Thibaud, shall I add you to the implementation team? It seems like you're
doing more work on this than I am lately. I think we could still use one or
perhaps two more people, but I think it's a good start.

On Mon, 14 Sep 2020 at 16:44, Carlton Gibson 
wrote:

> Hi All.
>
> Thanks for this. I'd be happy to play *Shepherd *if you need someone to
> put their hand up.
> I think that means I need to nag about getting it done. So... 
>
> Who's going to be on the team to do the first review, and then subsequent
> work? Answer that and you have the Implementation Team.
> I like that you've thought about how the team can refresh periodically — I
> don't suppose the burden will be too great but folks tend to cycle-out
> naturally, so good to plan for that.
> Thibaud: Asking for hands in your talk seems sensible.
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>
>> Hi all,
>>
>> Now that the DEP PR has been submitted I was wondering what the next
>> steps would be. According to the documented DEP process I found, it’s at
>> the "forming the team"
>> 
>> stage? How do you go about creating an *Implementation Team* and finding
>> a *Shepherd*?
>>
>> The main reason I ask is that I’ll be giving a talk about accessibility
>> at DjangoCon EU in a couple of weeks, and I thought it would be a good
>> occasion to raise awareness of the issues with the Django admin, and
>> mention this DEP. But I want to make sure I provide accurate information.
>>
>> Thanks in advance,
>>
>> Thibaud
>>
>> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>>
>>>  it’s wonderful to see this happening! Re-reading through the whole
>>> thing, as Tobias mentioned I also find it very easy to read, and makes a
>>> good case.
>>>
>>> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>>>
 I've added a PR to the DEPs repo to hopefully get some eyes on it:
 https://github.com/django/deps/pull/69

 Thibaud, I think whatever you have the time and motivation for sounds
 good, all of those things are useful. If you're not sure about all the
 admin features, I think that's pretty normal. One project I've had on my
 mind for a while now is to build a simple django site that is essentially
 just there to use every feature of the admin, so I might bump that up the
 priority list, though it's somewhat daunting.

 Cheers,
 Tom

 On Mon, 13 Jul 2020 at 01:15, Thibaud Colas 
 wrote:

> Update for the proof of concept CI tests from my side – thank you Tom
> for the feedback. Here are the latest additions to the test suite &
> reports, still living at
> https://thibaudcolas.github.io/django_admin_tests/,
>
> - Added as much as I know about in the admin, and now also outside of
> it a bit (startproject welcome page, error pages)
> - Separated the issues between Axe and HTML_CS so the numbers are
> easier to understand
> - Added anchor links everywhere for easier navigation
> - I’ve also started a draft list of "things to (potentially) audit",
> over at
> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>
> I think the next two big steps are what you mention:
>
> - Having a way to track the number of issues over time. Currently the
> report overwrites itself every week (well, every build). If you have a
> suggestion on ways to demo this that would be useful please let me know.
> Currently I’m thinking sparklines for each test case could be nice as a
> proof of concept, and a sparkline for the total number of issues. Or see
> whether I should get out of my comfort zone a bit and find a
> dashboard/graphing tool to send the metrics to and graph there.
> - Testing more features of modeladmin. I don’t use it too frequently
> myself so don’t really know what’s “easy” to enable – if you know of an
> existing test suite I could repurpose, or of an example of using a lot of
> functionality – I’d be keen to invest time to add it to my test site.
>
> Alternatively something else I could do is to file a ticket for
> accessibility issues with the welcome page – I’ve tested it with screen
> readers, there are a few issues, but nothing that should be too hard to
> fix, and it might be a good demo of what reporting accessibility issues in
> general could look like?
>
> Cheers,
>
> Thibaud
>
>
> On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:
>
>> Nice writeup! I found it easy to read (I did not catch myself
>> skipping
>> paragraphs which is always a good sign). Contentwise, I would have no
>> issue if this was accepted as is. Maybe I am forgetting about some
>> important 

Re: Admin accessibility

[Carlton Gibson]

Hi All. 

Thanks for this. I'd be happy to play *Shepherd *if you need someone to put 
their hand up. 
I think that means I need to nag about getting it done. So... 

Who's going to be on the team to do the first review, and then subsequent 
work? Answer that and you have the Implementation Team. 
I like that you've thought about how the team can refresh periodically — I 
don't suppose the burden will be too great but folks tend to cycle-out 
naturally, so good to plan for that. 
Thibaud: Asking for hands in your talk seems sensible. 

Kind Regards,

Carlton



On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:

> Hi all,
>
> Now that the DEP PR has been submitted I was wondering what the next steps 
> would be. According to the documented DEP process I found, it’s at the 
> "forming 
> the team" 
> 
>  
> stage? How do you go about creating an *Implementation Team* and finding 
> a *Shepherd*?
>
> The main reason I ask is that I’ll be giving a talk about accessibility at 
> DjangoCon EU in a couple of weeks, and I thought it would be a good 
> occasion to raise awareness of the issues with the Django admin, and 
> mention this DEP. But I want to make sure I provide accurate information.
>
> Thanks in advance,
>
> Thibaud
>
> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>
>>  it’s wonderful to see this happening! Re-reading through the whole 
>> thing, as Tobias mentioned I also find it very easy to read, and makes a 
>> good case.
>>
>> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>>
>>> I've added a PR to the DEPs repo to hopefully get some eyes on it: 
>>> https://github.com/django/deps/pull/69
>>>
>>> Thibaud, I think whatever you have the time and motivation for sounds 
>>> good, all of those things are useful. If you're not sure about all the 
>>> admin features, I think that's pretty normal. One project I've had on my 
>>> mind for a while now is to build a simple django site that is essentially 
>>> just there to use every feature of the admin, so I might bump that up the 
>>> priority list, though it's somewhat daunting.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  wrote:
>>>
 Update for the proof of concept CI tests from my side – thank you Tom 
 for the feedback. Here are the latest additions to the test suite & 
 reports, still living at 
 https://thibaudcolas.github.io/django_admin_tests/,

 - Added as much as I know about in the admin, and now also outside of 
 it a bit (startproject welcome page, error pages)
 - Separated the issues between Axe and HTML_CS so the numbers are 
 easier to understand
 - Added anchor links everywhere for easier navigation
 - I’ve also started a draft list of "things to (potentially) audit", 
 over at 
 https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits

 I think the next two big steps are what you mention:

 - Having a way to track the number of issues over time. Currently the 
 report overwrites itself every week (well, every build). If you have a 
 suggestion on ways to demo this that would be useful please let me know. 
 Currently I’m thinking sparklines for each test case could be nice as a 
 proof of concept, and a sparkline for the total number of issues. Or see 
 whether I should get out of my comfort zone a bit and find a 
 dashboard/graphing tool to send the metrics to and graph there.
 - Testing more features of modeladmin. I don’t use it too frequently 
 myself so don’t really know what’s “easy” to enable – if you know of an 
 existing test suite I could repurpose, or of an example of using a lot of 
 functionality – I’d be keen to invest time to add it to my test site.

 Alternatively something else I could do is to file a ticket for 
 accessibility issues with the welcome page – I’ve tested it with screen 
 readers, there are a few issues, but nothing that should be too hard to 
 fix, and it might be a good demo of what reporting accessibility issues in 
 general could look like?

 Cheers,

 Thibaud


 On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:

> Nice writeup! I found it easy to read (I did not catch myself skipping 
> paragraphs which is always a good sign). Contentwise, I would have no 
> issue if this was accepted as is. Maybe I am forgetting about some 
> important details though. 
>
> I had just some ideas that might be good additions: 
>
> - mention ATAG somewhere 
>
> - It would be nice to have a real commitment to accessibility. 
> Something 
> along the lines of "accessibility bugs must be treated with the same 
> priority as any other bugs". 
>
> - The step from "leaving accessibility in the hands 

Re: Admin accessibility

[Thibaud Colas]

Hi all,

Now that the DEP PR has been submitted I was wondering what the next steps 
would be. According to the documented DEP process I found, it’s at the "forming 
the team" 

 
stage? How do you go about creating an *Implementation Team* and finding a 
*Shepherd*?

The main reason I ask is that I’ll be giving a talk about accessibility at 
DjangoCon EU in a couple of weeks, and I thought it would be a good 
occasion to raise awareness of the issues with the Django admin, and 
mention this DEP. But I want to make sure I provide accurate information.

Thanks in advance,

Thibaud

On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:

>  it’s wonderful to see this happening! Re-reading through the whole 
> thing, as Tobias mentioned I also find it very easy to read, and makes a 
> good case.
>
> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>
>> I've added a PR to the DEPs repo to hopefully get some eyes on it: 
>> https://github.com/django/deps/pull/69
>>
>> Thibaud, I think whatever you have the time and motivation for sounds 
>> good, all of those things are useful. If you're not sure about all the 
>> admin features, I think that's pretty normal. One project I've had on my 
>> mind for a while now is to build a simple django site that is essentially 
>> just there to use every feature of the admin, so I might bump that up the 
>> priority list, though it's somewhat daunting.
>>
>> Cheers,
>> Tom
>>
>> On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  wrote:
>>
>>> Update for the proof of concept CI tests from my side – thank you Tom 
>>> for the feedback. Here are the latest additions to the test suite & 
>>> reports, still living at 
>>> https://thibaudcolas.github.io/django_admin_tests/,
>>>
>>> - Added as much as I know about in the admin, and now also outside of it 
>>> a bit (startproject welcome page, error pages)
>>> - Separated the issues between Axe and HTML_CS so the numbers are easier 
>>> to understand
>>> - Added anchor links everywhere for easier navigation
>>> - I’ve also started a draft list of "things to (potentially) audit", 
>>> over at 
>>> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>>>
>>> I think the next two big steps are what you mention:
>>>
>>> - Having a way to track the number of issues over time. Currently the 
>>> report overwrites itself every week (well, every build). If you have a 
>>> suggestion on ways to demo this that would be useful please let me know. 
>>> Currently I’m thinking sparklines for each test case could be nice as a 
>>> proof of concept, and a sparkline for the total number of issues. Or see 
>>> whether I should get out of my comfort zone a bit and find a 
>>> dashboard/graphing tool to send the metrics to and graph there.
>>> - Testing more features of modeladmin. I don’t use it too frequently 
>>> myself so don’t really know what’s “easy” to enable – if you know of an 
>>> existing test suite I could repurpose, or of an example of using a lot of 
>>> functionality – I’d be keen to invest time to add it to my test site.
>>>
>>> Alternatively something else I could do is to file a ticket for 
>>> accessibility issues with the welcome page – I’ve tested it with screen 
>>> readers, there are a few issues, but nothing that should be too hard to 
>>> fix, and it might be a good demo of what reporting accessibility issues in 
>>> general could look like?
>>>
>>> Cheers,
>>>
>>> Thibaud
>>>
>>>
>>> On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:
>>>
 Nice writeup! I found it easy to read (I did not catch myself skipping 
 paragraphs which is always a good sign). Contentwise, I would have no 
 issue if this was accepted as is. Maybe I am forgetting about some 
 important details though. 

 I had just some ideas that might be good additions: 

 - mention ATAG somewhere 

 - It would be nice to have a real commitment to accessibility. 
 Something 
 along the lines of "accessibility bugs must be treated with the same 
 priority as any other bugs". 

 - The step from "leaving accessibility in the hands of 
 individual contributors" to "you have to commit for 9 months" is a tad 
 big. I keep wondering if we can do something to improve the options in 
 between those. One idea would be to formalize an "a11y" keyword so 
 interested contributors can easily find related tickets. 

 tobias 

>>> -- 
>>>
>> 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-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> 

#31617 new New feature Improve overall admin accessibility.

[Abishek Rajagopal]

Hello Team,

   I'm ready to work on this issue. Im a Full Stack dev by 
profession. I need to know what are necessary thing that i need to change 
and how do get the original code of that page. 

-- 
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/c05163c4-6f43-4abc-ae98-8a6fd457382fo%40googlegroups.com.

Re: Admin accessibility

[Thibaud Colas]

 it’s wonderful to see this happening! Re-reading through the whole 
thing, as Tobias mentioned I also find it very easy to read, and makes a 
good case.

On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:

> I've added a PR to the DEPs repo to hopefully get some eyes on it: 
> https://github.com/django/deps/pull/69
>
> Thibaud, I think whatever you have the time and motivation for sounds 
> good, all of those things are useful. If you're not sure about all the 
> admin features, I think that's pretty normal. One project I've had on my 
> mind for a while now is to build a simple django site that is essentially 
> just there to use every feature of the admin, so I might bump that up the 
> priority list, though it's somewhat daunting.
>
> Cheers,
> Tom
>
> On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  wrote:
>
>> Update for the proof of concept CI tests from my side – thank you Tom for 
>> the feedback. Here are the latest additions to the test suite & reports, 
>> still living at https://thibaudcolas.github.io/django_admin_tests/,
>>
>> - Added as much as I know about in the admin, and now also outside of it 
>> a bit (startproject welcome page, error pages)
>> - Separated the issues between Axe and HTML_CS so the numbers are easier 
>> to understand
>> - Added anchor links everywhere for easier navigation
>> - I’ve also started a draft list of "things to (potentially) audit", over 
>> at 
>> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>>
>> I think the next two big steps are what you mention:
>>
>> - Having a way to track the number of issues over time. Currently the 
>> report overwrites itself every week (well, every build). If you have a 
>> suggestion on ways to demo this that would be useful please let me know. 
>> Currently I’m thinking sparklines for each test case could be nice as a 
>> proof of concept, and a sparkline for the total number of issues. Or see 
>> whether I should get out of my comfort zone a bit and find a 
>> dashboard/graphing tool to send the metrics to and graph there.
>> - Testing more features of modeladmin. I don’t use it too frequently 
>> myself so don’t really know what’s “easy” to enable – if you know of an 
>> existing test suite I could repurpose, or of an example of using a lot of 
>> functionality – I’d be keen to invest time to add it to my test site.
>>
>> Alternatively something else I could do is to file a ticket for 
>> accessibility issues with the welcome page – I’ve tested it with screen 
>> readers, there are a few issues, but nothing that should be too hard to 
>> fix, and it might be a good demo of what reporting accessibility issues in 
>> general could look like?
>>
>> Cheers,
>>
>> Thibaud
>>
>>
>> On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:
>>
>>> Nice writeup! I found it easy to read (I did not catch myself skipping 
>>> paragraphs which is always a good sign). Contentwise, I would have no 
>>> issue if this was accepted as is. Maybe I am forgetting about some 
>>> important details though. 
>>>
>>> I had just some ideas that might be good additions: 
>>>
>>> - mention ATAG somewhere 
>>>
>>> - It would be nice to have a real commitment to accessibility. Something 
>>> along the lines of "accessibility bugs must be treated with the same 
>>> priority as any other bugs". 
>>>
>>> - The step from "leaving accessibility in the hands of 
>>> individual contributors" to "you have to commit for 9 months" is a tad 
>>> big. I keep wondering if we can do something to improve the options in 
>>> between those. One idea would be to formalize an "a11y" keyword so 
>>> interested contributors can easily find related tickets. 
>>>
>>> tobias 
>>>
>> -- 
>>
> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/e65e3879-d74c-4401-9232-29eb0a73385cn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/6e323a74-38a7-4c64-9b22-4c71c6410056n%40googlegroups.com.

Re: Admin accessibility

[Tom Carrick]

I've added a PR to the DEPs repo to hopefully get some eyes on it:
https://github.com/django/deps/pull/69

Thibaud, I think whatever you have the time and motivation for sounds good,
all of those things are useful. If you're not sure about all the admin
features, I think that's pretty normal. One project I've had on my mind for
a while now is to build a simple django site that is essentially just there
to use every feature of the admin, so I might bump that up the priority
list, though it's somewhat daunting.

Cheers,
Tom

On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  wrote:

> Update for the proof of concept CI tests from my side – thank you Tom for
> the feedback. Here are the latest additions to the test suite & reports,
> still living at https://thibaudcolas.github.io/django_admin_tests/,
>
> - Added as much as I know about in the admin, and now also outside of it a
> bit (startproject welcome page, error pages)
> - Separated the issues between Axe and HTML_CS so the numbers are easier
> to understand
> - Added anchor links everywhere for easier navigation
> - I’ve also started a draft list of "things to (potentially) audit", over
> at
> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>
> I think the next two big steps are what you mention:
>
> - Having a way to track the number of issues over time. Currently the
> report overwrites itself every week (well, every build). If you have a
> suggestion on ways to demo this that would be useful please let me know.
> Currently I’m thinking sparklines for each test case could be nice as a
> proof of concept, and a sparkline for the total number of issues. Or see
> whether I should get out of my comfort zone a bit and find a
> dashboard/graphing tool to send the metrics to and graph there.
> - Testing more features of modeladmin. I don’t use it too frequently
> myself so don’t really know what’s “easy” to enable – if you know of an
> existing test suite I could repurpose, or of an example of using a lot of
> functionality – I’d be keen to invest time to add it to my test site.
>
> Alternatively something else I could do is to file a ticket for
> accessibility issues with the welcome page – I’ve tested it with screen
> readers, there are a few issues, but nothing that should be too hard to
> fix, and it might be a good demo of what reporting accessibility issues in
> general could look like?
>
> Cheers,
>
> Thibaud
>
>
> On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:
>
>> Nice writeup! I found it easy to read (I did not catch myself skipping
>> paragraphs which is always a good sign). Contentwise, I would have no
>> issue if this was accepted as is. Maybe I am forgetting about some
>> important details though.
>>
>> I had just some ideas that might be good additions:
>>
>> - mention ATAG somewhere
>>
>> - It would be nice to have a real commitment to accessibility. Something
>> along the lines of "accessibility bugs must be treated with the same
>> priority as any other bugs".
>>
>> - The step from "leaving accessibility in the hands of
>> individual contributors" to "you have to commit for 9 months" is a tad
>> big. I keep wondering if we can do something to improve the options in
>> between those. One idea would be to formalize an "a11y" keyword so
>> interested contributors can easily find related tickets.
>>
>> tobias
>>
> --
> 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/e65e3879-d74c-4401-9232-29eb0a73385cn%40googlegroups.com
> 
> .
>

-- 
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%3DMZ_%2BR%2BMWxeJtsQt1%3DW-9hT-wS7Nk7ALUKnozDaRKzQFbw%40mail.gmail.com.

Re: Admin accessibility

[Thibaud Colas]

Update for the proof of concept CI tests from my side – thank you Tom for 
the feedback. Here are the latest additions to the test suite & reports, 
still living at https://thibaudcolas.github.io/django_admin_tests/,

- Added as much as I know about in the admin, and now also outside of it a 
bit (startproject welcome page, error pages)
- Separated the issues between Axe and HTML_CS so the numbers are easier to 
understand
- Added anchor links everywhere for easier navigation
- I’ve also started a draft list of "things to (potentially) audit", over 
at 
https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits

I think the next two big steps are what you mention:

- Having a way to track the number of issues over time. Currently the 
report overwrites itself every week (well, every build). If you have a 
suggestion on ways to demo this that would be useful please let me know. 
Currently I’m thinking sparklines for each test case could be nice as a 
proof of concept, and a sparkline for the total number of issues. Or see 
whether I should get out of my comfort zone a bit and find a 
dashboard/graphing tool to send the metrics to and graph there.
- Testing more features of modeladmin. I don’t use it too frequently myself 
so don’t really know what’s “easy” to enable – if you know of an existing 
test suite I could repurpose, or of an example of using a lot of 
functionality – I’d be keen to invest time to add it to my test site.

Alternatively something else I could do is to file a ticket for 
accessibility issues with the welcome page – I’ve tested it with screen 
readers, there are a few issues, but nothing that should be too hard to 
fix, and it might be a good demo of what reporting accessibility issues in 
general could look like?

Cheers,

Thibaud


On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:

> Nice writeup! I found it easy to read (I did not catch myself skipping
> paragraphs which is always a good sign). Contentwise, I would have no
> issue if this was accepted as is. Maybe I am forgetting about some
> important details though.
>
> I had just some ideas that might be good additions:
>
> - mention ATAG somewhere
>
> - It would be nice to have a real commitment to accessibility. Something
> along the lines of "accessibility bugs must be treated with the same
> priority as any other bugs".
>
> - The step from "leaving accessibility in the hands of
> individual contributors" to "you have to commit for 9 months" is a tad
> big. I keep wondering if we can do something to improve the options in
> between those. One idea would be to formalize an "a11y" keyword so
> interested contributors can easily find related tickets.
>
> tobias
>

-- 
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/e65e3879-d74c-4401-9232-29eb0a73385cn%40googlegroups.com.

Re: Admin accessibility

[Tobias Bengfort]

Nice writeup! I found it easy to read (I did not catch myself skipping
paragraphs which is always a good sign). Contentwise, I would have no
issue if this was accepted as is. Maybe I am forgetting about some
important details though.

I had just some ideas that might be good additions:

- mention ATAG somewhere

- It would be nice to have a real commitment to accessibility. Something
along the lines of "accessibility bugs must be treated with the same
priority as any other bugs".

- The step from "leaving accessibility in the hands of
individual contributors" to "you have to commit for 9 months" is a tad
big. I keep wondering if we can do something to improve the options in
between those. One idea would be to formalize an "a11y" keyword so
interested contributors can easily find related tickets.

tobias

-- 
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/9b194f07-8d00-0540-109a-190ee950d92a%40posteo.de.

Re: Admin accessibility

[Tom Carrick]

I've had some time to work on this, I've written up a draft... draft DEP
today, and I'd like to request feedback. I've written it quite hastily over
the last few hours with the expectation that it will need to be
substantially rewritten. I've added it as a local PR on my fork of DEPS to
keep the discussion in one place. I'm happy to take broad feedback here,
but try to keep specific feedback on the PR itself to keep the noise off
this thread. PR: https://github.com/knyghty/deps/pull/1

I'm also requesting someone to shepherd this, and ideally also a co-author,
particularly someone on the technical board, a core dev, or someone else
with experience of Django's governance, as I think this is the first
process DEP written by a non-core dev.

Cheers!
Tom

On Thu, 25 Jun 2020 at 19:31, Tom Carrick  wrote:

> I've managed to have a quick look, it looks really promising. Having a
> total number of issues to compare against would be good to avoid
> regressions or introducing new issues. I do have one concern. To be viable,
> it needs to live in the django repo somewhere. And we'd need a full admin
> site to test against, with every admin feature (stacked / tabular inlines,
> filtering, search, date filters, list editable, autocomplete, ...) to be
> fully representative and catch everything. This seems like a really big
> amount of stuff to add into the repo, that will need to be maintained, and
> possibly an easy thing to forget about. Also the maintenance is tricky, we
> should ideally not update this site too often or the total number of issues
> won't be as easily comparable. I wonder if there's another way to handle
> it, but I can't think of one.
>
> I also imagine this would be pretty intensive to run, it would probably be
> best to not run it by default and have a buildbot command to run this
> manually for PRs where there are changes to the admin.
>
> On Thu, 25 Jun 2020 at 02:15, Thibaud Colas 
> wrote:
>
>> Hi Tom,
>>
>> Great to hear – no rush if you’re busy with other things. Here’s a quick
>> proof of concept, with 20 different pages/scenarios, tested with Axe, HTML
>> Code Sniffer, and Lighthouse:
>> https://github.com/thibaudcolas/django_admin_tests.
>>
>> I’m not a big fan of Lighthouse personally, and I already had the rest of
>> the tools set up, hence why I went with this. I spent a bit of time making
>> a report out of the test results, which you can see an example of at
>> https://thibaudcolas.github.io/django_admin_tests/. This is generated in
>> Travis, currently set up to run those tests & regenerate the report from
>> Django’s `master` branch once per week.
>>
>> I added instructions on the README to run this locally if anyone wants to
>> try it out, and a few words about what to make of the report / issues. I
>> didn’t look into what the issues were though.
>>
>> Let me know what you think, and I should be able to spend more time on
>> this next week if it helps.
>>
>> On Wednesday, 24 June 2020 at 09:11:52 UTC+1 t...@carrick.eu wrote:
>>
>>> A quick update first. I'm pretty busy with a combination of day job and
>>> personal projects, but I should have time to start writing the draft DEP in
>>> the next week or two.
>>>
>>> Thibaud, I think the absolute most important thing is a way to measure
>>> progress, even if - as others have mentioned - that measure is imperfect. I
>>> think getting a proof of concept of Lighthouse running against a few admin
>>> pages would be extremely helpful. It's also probably one of the more
>>> difficult things. If that seems like too much, I think catching what the CI
>>> would miss is the next most important thing, so I think your #1 suggestion
>>> would work well.
>>>
>>> On Tue, 23 Jun 2020 at 22:34, Thibaud Colas  wrote:
>>>
 Hey Tom,

 I wanted to check if there is anything we/I could do to help in the
 meantime? Whether that’s by starting to map or audit the Django admin, or
 setting up a sample CI pipeline with accessibility tests, or something else
 altogether. It’s a bit daunting to get started with this but I think I
 could realistically do one of:

 1. Create a draft map of the Django admin UI for later manual auditing
 purposes.
 2. Audi a specific part of Django and creating a ticket with concrete
 things to fix.
 3. Set up static analysis for the CSS or HTML to look for common
 accessibility gotchas.
 4. Sett up automated in-browser accessibility checks on some parts of
 Django to show what that might look like in a CI pipeline.

 … and document the steps along the way, and report back here or as a
 ticket.

 Cheers,

 Thibaud

 On Tuesday, May 26, 2020 at 10:22:26 AM UTC+1, Tom Carrick wrote:
>
> Some further thoughts...
>
> Mariusz, I don't think I agree that WCAG is massive. It can look a
> little large but I think that's mostly because each guideline is split 
> into
> smaller pieces and it's quite wordy to 

Re: Admin accessibility

[Tom Carrick]

I've managed to have a quick look, it looks really promising. Having a
total number of issues to compare against would be good to avoid
regressions or introducing new issues. I do have one concern. To be viable,
it needs to live in the django repo somewhere. And we'd need a full admin
site to test against, with every admin feature (stacked / tabular inlines,
filtering, search, date filters, list editable, autocomplete, ...) to be
fully representative and catch everything. This seems like a really big
amount of stuff to add into the repo, that will need to be maintained, and
possibly an easy thing to forget about. Also the maintenance is tricky, we
should ideally not update this site too often or the total number of issues
won't be as easily comparable. I wonder if there's another way to handle
it, but I can't think of one.

I also imagine this would be pretty intensive to run, it would probably be
best to not run it by default and have a buildbot command to run this
manually for PRs where there are changes to the admin.

On Thu, 25 Jun 2020 at 02:15, Thibaud Colas  wrote:

> Hi Tom,
>
> Great to hear – no rush if you’re busy with other things. Here’s a quick
> proof of concept, with 20 different pages/scenarios, tested with Axe, HTML
> Code Sniffer, and Lighthouse:
> https://github.com/thibaudcolas/django_admin_tests.
>
> I’m not a big fan of Lighthouse personally, and I already had the rest of
> the tools set up, hence why I went with this. I spent a bit of time making
> a report out of the test results, which you can see an example of at
> https://thibaudcolas.github.io/django_admin_tests/. This is generated in
> Travis, currently set up to run those tests & regenerate the report from
> Django’s `master` branch once per week.
>
> I added instructions on the README to run this locally if anyone wants to
> try it out, and a few words about what to make of the report / issues. I
> didn’t look into what the issues were though.
>
> Let me know what you think, and I should be able to spend more time on
> this next week if it helps.
>
> On Wednesday, 24 June 2020 at 09:11:52 UTC+1 t...@carrick.eu wrote:
>
>> A quick update first. I'm pretty busy with a combination of day job and
>> personal projects, but I should have time to start writing the draft DEP in
>> the next week or two.
>>
>> Thibaud, I think the absolute most important thing is a way to measure
>> progress, even if - as others have mentioned - that measure is imperfect. I
>> think getting a proof of concept of Lighthouse running against a few admin
>> pages would be extremely helpful. It's also probably one of the more
>> difficult things. If that seems like too much, I think catching what the CI
>> would miss is the next most important thing, so I think your #1 suggestion
>> would work well.
>>
>> On Tue, 23 Jun 2020 at 22:34, Thibaud Colas  wrote:
>>
>>> Hey Tom,
>>>
>>> I wanted to check if there is anything we/I could do to help in the
>>> meantime? Whether that’s by starting to map or audit the Django admin, or
>>> setting up a sample CI pipeline with accessibility tests, or something else
>>> altogether. It’s a bit daunting to get started with this but I think I
>>> could realistically do one of:
>>>
>>> 1. Create a draft map of the Django admin UI for later manual auditing
>>> purposes.
>>> 2. Audi a specific part of Django and creating a ticket with concrete
>>> things to fix.
>>> 3. Set up static analysis for the CSS or HTML to look for common
>>> accessibility gotchas.
>>> 4. Sett up automated in-browser accessibility checks on some parts of
>>> Django to show what that might look like in a CI pipeline.
>>>
>>> … and document the steps along the way, and report back here or as a
>>> ticket.
>>>
>>> Cheers,
>>>
>>> Thibaud
>>>
>>> On Tuesday, May 26, 2020 at 10:22:26 AM UTC+1, Tom Carrick wrote:

 Some further thoughts...

 Mariusz, I don't think I agree that WCAG is massive. It can look a
 little large but I think that's mostly because each guideline is split into
 smaller pieces and it's quite wordy to avoid ambiguity. There are in 2.1 50
 success criteria for AA, many of which can be checked automatically, and
 many of those that can't don't apply to us as we don't use audio / video.
 There's also a nice quick reference
  that can be filtered to
 remove AAA and anything else unwanted. Once you drill down it can again get
 quite wordy, but it covers a lot. I think it's worth remembering here is
 that the point is not to strictly adhere to a standard for the sake of it,
 just to improve the overall accessibility, and WCAG is a useful and
 measurable tool to get us some of the way there.

 Thibaud, I more or less agree with everything there. I'm not sure
 developers should have to do full accessibility checks for their changes in
 the admin. Using a screen reader for example can be very frustrating and
 confusing if 

Re: Admin accessibility

[Thibaud Colas]

Hi Tom,

Great to hear – no rush if you’re busy with other things. Here’s a quick 
proof of concept, with 20 different pages/scenarios, tested with Axe, HTML 
Code Sniffer, and Lighthouse: 
https://github.com/thibaudcolas/django_admin_tests.

I’m not a big fan of Lighthouse personally, and I already had the rest of 
the tools set up, hence why I went with this. I spent a bit of time making 
a report out of the test results, which you can see an example of at 
https://thibaudcolas.github.io/django_admin_tests/. This is generated in 
Travis, currently set up to run those tests & regenerate the report from 
Django’s `master` branch once per week.

I added instructions on the README to run this locally if anyone wants to 
try it out, and a few words about what to make of the report / issues. I 
didn’t look into what the issues were though.

Let me know what you think, and I should be able to spend more time on this 
next week if it helps.

On Wednesday, 24 June 2020 at 09:11:52 UTC+1 t...@carrick.eu wrote:

> A quick update first. I'm pretty busy with a combination of day job and 
> personal projects, but I should have time to start writing the draft DEP in 
> the next week or two.
>
> Thibaud, I think the absolute most important thing is a way to measure 
> progress, even if - as others have mentioned - that measure is imperfect. I 
> think getting a proof of concept of Lighthouse running against a few admin 
> pages would be extremely helpful. It's also probably one of the more 
> difficult things. If that seems like too much, I think catching what the CI 
> would miss is the next most important thing, so I think your #1 suggestion 
> would work well.
>
> On Tue, 23 Jun 2020 at 22:34, Thibaud Colas  wrote:
>
>> Hey Tom,
>>
>> I wanted to check if there is anything we/I could do to help in the 
>> meantime? Whether that’s by starting to map or audit the Django admin, or 
>> setting up a sample CI pipeline with accessibility tests, or something else 
>> altogether. It’s a bit daunting to get started with this but I think I 
>> could realistically do one of:
>>
>> 1. Create a draft map of the Django admin UI for later manual auditing 
>> purposes.
>> 2. Audi a specific part of Django and creating a ticket with concrete 
>> things to fix.
>> 3. Set up static analysis for the CSS or HTML to look for common 
>> accessibility gotchas.
>> 4. Sett up automated in-browser accessibility checks on some parts of 
>> Django to show what that might look like in a CI pipeline.
>>
>> … and document the steps along the way, and report back here or as a 
>> ticket.
>>
>> Cheers,
>>
>> Thibaud
>>
>> On Tuesday, May 26, 2020 at 10:22:26 AM UTC+1, Tom Carrick wrote:
>>>
>>> Some further thoughts...
>>>
>>> Mariusz, I don't think I agree that WCAG is massive. It can look a 
>>> little large but I think that's mostly because each guideline is split into 
>>> smaller pieces and it's quite wordy to avoid ambiguity. There are in 2.1 50 
>>> success criteria for AA, many of which can be checked automatically, and 
>>> many of those that can't don't apply to us as we don't use audio / video. 
>>> There's also a nice quick reference 
>>>  that can be filtered to 
>>> remove AAA and anything else unwanted. Once you drill down it can again get 
>>> quite wordy, but it covers a lot. I think it's worth remembering here is 
>>> that the point is not to strictly adhere to a standard for the sake of it, 
>>> just to improve the overall accessibility, and WCAG is a useful and 
>>> measurable tool to get us some of the way there.
>>>
>>> Thibaud, I more or less agree with everything there. I'm not sure 
>>> developers should have to do full accessibility checks for their changes in 
>>> the admin. Using a screen reader for example can be very frustrating and 
>>> confusing if you're not used to it, and it can take an inordinate amount of 
>>> time, and I don't really wish that burden on (for example) first time 
>>> committers who already have a lot of stuff to do, I think this will only 
>>> discourage contributions. I think it should be the responsibility of the 
>>> accessibility team to provide feedback, suggestions, etc. on relevant PRs 
>>> or fix things when they're noticed after manual audits.
>>>
>>> ATAG looks handy, but at first glance we couldn't even get to A, it 
>>> requires auto-saving. It also generally seems like something that would 
>>> cover a rich text editor plugged into the admin more than the admin itself, 
>>> though I think it's laudable as a future target.
>>>
>>> The more I think about it, I think the DEP should be a process DEP 
>>> rather than a feature DEP. As others have mentioned, we don't need a DEP to 
>>> fix accessibility issues - just fix them. But forming a team seems useful, 
>>> and I think a DEP is required for that. I think the DEP should be limited 
>>> to:
>>>
>>> 1. The accessibility team, how membership is decided, who it's 
>>> accountable to, it's 

Re: Admin accessibility

[Tom Carrick]

A quick update first. I'm pretty busy with a combination of day job and
personal projects, but I should have time to start writing the draft DEP in
the next week or two.

Thibaud, I think the absolute most important thing is a way to measure
progress, even if - as others have mentioned - that measure is imperfect. I
think getting a proof of concept of Lighthouse running against a few admin
pages would be extremely helpful. It's also probably one of the more
difficult things. If that seems like too much, I think catching what the CI
would miss is the next most important thing, so I think your #1 suggestion
would work well.

On Tue, 23 Jun 2020 at 22:34, Thibaud Colas  wrote:

> Hey Tom,
>
> I wanted to check if there is anything we/I could do to help in the
> meantime? Whether that’s by starting to map or audit the Django admin, or
> setting up a sample CI pipeline with accessibility tests, or something else
> altogether. It’s a bit daunting to get started with this but I think I
> could realistically do one of:
>
> 1. Create a draft map of the Django admin UI for later manual auditing
> purposes.
> 2. Audi a specific part of Django and creating a ticket with concrete
> things to fix.
> 3. Set up static analysis for the CSS or HTML to look for common
> accessibility gotchas.
> 4. Sett up automated in-browser accessibility checks on some parts of
> Django to show what that might look like in a CI pipeline.
>
> … and document the steps along the way, and report back here or as a
> ticket.
>
> Cheers,
>
> Thibaud
>
> On Tuesday, May 26, 2020 at 10:22:26 AM UTC+1, Tom Carrick wrote:
>>
>> Some further thoughts...
>>
>> Mariusz, I don't think I agree that WCAG is massive. It can look a little
>> large but I think that's mostly because each guideline is split into
>> smaller pieces and it's quite wordy to avoid ambiguity. There are in 2.1 50
>> success criteria for AA, many of which can be checked automatically, and
>> many of those that can't don't apply to us as we don't use audio / video.
>> There's also a nice quick reference
>>  that can be filtered to remove
>> AAA and anything else unwanted. Once you drill down it can again get quite
>> wordy, but it covers a lot. I think it's worth remembering here is that the
>> point is not to strictly adhere to a standard for the sake of it, just to
>> improve the overall accessibility, and WCAG is a useful and measurable tool
>> to get us some of the way there.
>>
>> Thibaud, I more or less agree with everything there. I'm not sure
>> developers should have to do full accessibility checks for their changes in
>> the admin. Using a screen reader for example can be very frustrating and
>> confusing if you're not used to it, and it can take an inordinate amount of
>> time, and I don't really wish that burden on (for example) first time
>> committers who already have a lot of stuff to do, I think this will only
>> discourage contributions. I think it should be the responsibility of the
>> accessibility team to provide feedback, suggestions, etc. on relevant PRs
>> or fix things when they're noticed after manual audits.
>>
>> ATAG looks handy, but at first glance we couldn't even get to A, it
>> requires auto-saving. It also generally seems like something that would
>> cover a rich text editor plugged into the admin more than the admin itself,
>> though I think it's laudable as a future target.
>>
>> The more I think about it, I think the DEP should be a process DEP rather
>> than a feature DEP. As others have mentioned, we don't need a DEP to fix
>> accessibility issues - just fix them. But forming a team seems useful, and
>> I think a DEP is required for that. I think the DEP should be limited to:
>>
>> 1. The accessibility team, how membership is decided, who it's
>> accountable to, it's role/responsibilities, etc.
>> 2. Perhaps the initial standard(s) to target, although this could also be
>> decided by the a11y team post-assembly and agreed with the technical board
>> and/or core devs.
>>
>> As I said, I'm happy to write up the DEP, but since it'll be a process
>> DEP, I think I'd need the support of a core dev, someone on the technical
>> board, or just someone who has more knowledge of Django's "bureaucracy",
>> for lack of a better word.
>>
>> Tom
>>
>> On Tue, 26 May 2020 at 01:20, Thibaud Colas  wrote:
>>
>>> Hi Tom,
>>>
>>> It’s exciting to see this getting started! To me a DEP would be highly
>>> beneficial, because there is a lot to this that goes beyond finding and
>>> fixing individual issues – it’s more about detailing the a process for
>>> parts of Django to stay accessible over time. Here are things I’d suggest
>>> to cover, in addition to your list:
>>>
>>> - Going further than the targeted standard and tests in CI –  outline
>>> clear steps developers should take when testing their work: using developer
>>> tools, screen readers, etc. It’s not practical to just state the standard
>>> as WCAG is quite big, and 

Re: Admin accessibility

[Thibaud Colas]

Hey Tom,

I wanted to check if there is anything we/I could do to help in the 
meantime? Whether that’s by starting to map or audit the Django admin, or 
setting up a sample CI pipeline with accessibility tests, or something else 
altogether. It’s a bit daunting to get started with this but I think I 
could realistically do one of:

1. Create a draft map of the Django admin UI for later manual auditing 
purposes.
2. Audi a specific part of Django and creating a ticket with concrete 
things to fix.
3. Set up static analysis for the CSS or HTML to look for common 
accessibility gotchas.
4. Sett up automated in-browser accessibility checks on some parts of 
Django to show what that might look like in a CI pipeline.

… and document the steps along the way, and report back here or as a ticket.

Cheers,

Thibaud

On Tuesday, May 26, 2020 at 10:22:26 AM UTC+1, Tom Carrick wrote:
>
> Some further thoughts...
>
> Mariusz, I don't think I agree that WCAG is massive. It can look a little 
> large but I think that's mostly because each guideline is split into 
> smaller pieces and it's quite wordy to avoid ambiguity. There are in 2.1 50 
> success criteria for AA, many of which can be checked automatically, and 
> many of those that can't don't apply to us as we don't use audio / video. 
> There's also a nice quick reference 
>  that can be filtered to remove 
> AAA and anything else unwanted. Once you drill down it can again get quite 
> wordy, but it covers a lot. I think it's worth remembering here is that the 
> point is not to strictly adhere to a standard for the sake of it, just to 
> improve the overall accessibility, and WCAG is a useful and measurable tool 
> to get us some of the way there.
>
> Thibaud, I more or less agree with everything there. I'm not sure 
> developers should have to do full accessibility checks for their changes in 
> the admin. Using a screen reader for example can be very frustrating and 
> confusing if you're not used to it, and it can take an inordinate amount of 
> time, and I don't really wish that burden on (for example) first time 
> committers who already have a lot of stuff to do, I think this will only 
> discourage contributions. I think it should be the responsibility of the 
> accessibility team to provide feedback, suggestions, etc. on relevant PRs 
> or fix things when they're noticed after manual audits.
>
> ATAG looks handy, but at first glance we couldn't even get to A, it 
> requires auto-saving. It also generally seems like something that would 
> cover a rich text editor plugged into the admin more than the admin itself, 
> though I think it's laudable as a future target.
>
> The more I think about it, I think the DEP should be a process DEP rather 
> than a feature DEP. As others have mentioned, we don't need a DEP to fix 
> accessibility issues - just fix them. But forming a team seems useful, and 
> I think a DEP is required for that. I think the DEP should be limited to:
>
> 1. The accessibility team, how membership is decided, who it's accountable 
> to, it's role/responsibilities, etc.
> 2. Perhaps the initial standard(s) to target, although this could also be 
> decided by the a11y team post-assembly and agreed with the technical board 
> and/or core devs.
>
> As I said, I'm happy to write up the DEP, but since it'll be a process 
> DEP, I think I'd need the support of a core dev, someone on the technical 
> board, or just someone who has more knowledge of Django's "bureaucracy", 
> for lack of a better word.
>
> Tom
>
> On Tue, 26 May 2020 at 01:20, Thibaud Colas  > wrote:
>
>> Hi Tom,
>>
>> It’s exciting to see this getting started! To me a DEP would be highly 
>> beneficial, because there is a lot to this that goes beyond finding and 
>> fixing individual issues – it’s more about detailing the a process for 
>> parts of Django to stay accessible over time. Here are things I’d suggest 
>> to cover, in addition to your list:
>>
>> - Going further than the targeted standard and tests in CI –  outline 
>> clear steps developers should take when testing their work: using developer 
>> tools, screen readers, etc. It’s not practical to just state the standard 
>> as WCAG is quite big, and open to interpretation. And CI testing will never 
>> be enough to reach any degree of compliance.
>>   - I’m not familiar with Django’s development process but generally I 
>> would recommend to use a combination of linting, browser extensions, manual 
>> testing instructions – and CI tests.
>> - If the accessibility team was to cover more than the Django admin, I 
>> think it would be worthwhile to also include accessibility of sites built 
>> with Django. Django is largely unopinionated about markup, but I remember 
>> its forms markup not being particularly good for screen readers, and the 
>> HTML code snippets in the docs would also be worth reviewing.
>> - Same goes for admin docs – not too familiar with them myself so I’m not 

Re: Admin accessibility

[Tom Carrick]

Some further thoughts...

Mariusz, I don't think I agree that WCAG is massive. It can look a little
large but I think that's mostly because each guideline is split into
smaller pieces and it's quite wordy to avoid ambiguity. There are in 2.1 50
success criteria for AA, many of which can be checked automatically, and
many of those that can't don't apply to us as we don't use audio / video.
There's also a nice quick reference
 that can be filtered to remove
AAA and anything else unwanted. Once you drill down it can again get quite
wordy, but it covers a lot. I think it's worth remembering here is that the
point is not to strictly adhere to a standard for the sake of it, just to
improve the overall accessibility, and WCAG is a useful and measurable tool
to get us some of the way there.

Thibaud, I more or less agree with everything there. I'm not sure
developers should have to do full accessibility checks for their changes in
the admin. Using a screen reader for example can be very frustrating and
confusing if you're not used to it, and it can take an inordinate amount of
time, and I don't really wish that burden on (for example) first time
committers who already have a lot of stuff to do, I think this will only
discourage contributions. I think it should be the responsibility of the
accessibility team to provide feedback, suggestions, etc. on relevant PRs
or fix things when they're noticed after manual audits.

ATAG looks handy, but at first glance we couldn't even get to A, it
requires auto-saving. It also generally seems like something that would
cover a rich text editor plugged into the admin more than the admin itself,
though I think it's laudable as a future target.

The more I think about it, I think the DEP should be a process DEP rather
than a feature DEP. As others have mentioned, we don't need a DEP to fix
accessibility issues - just fix them. But forming a team seems useful, and
I think a DEP is required for that. I think the DEP should be limited to:

1. The accessibility team, how membership is decided, who it's accountable
to, it's role/responsibilities, etc.
2. Perhaps the initial standard(s) to target, although this could also be
decided by the a11y team post-assembly and agreed with the technical board
and/or core devs.

As I said, I'm happy to write up the DEP, but since it'll be a process DEP,
I think I'd need the support of a core dev, someone on the technical board,
or just someone who has more knowledge of Django's "bureaucracy", for lack
of a better word.

Tom

On Tue, 26 May 2020 at 01:20, Thibaud Colas  wrote:

> Hi Tom,
>
> It’s exciting to see this getting started! To me a DEP would be highly
> beneficial, because there is a lot to this that goes beyond finding and
> fixing individual issues – it’s more about detailing the a process for
> parts of Django to stay accessible over time. Here are things I’d suggest
> to cover, in addition to your list:
>
> - Going further than the targeted standard and tests in CI –  outline
> clear steps developers should take when testing their work: using developer
> tools, screen readers, etc. It’s not practical to just state the standard
> as WCAG is quite big, and open to interpretation. And CI testing will never
> be enough to reach any degree of compliance.
>   - I’m not familiar with Django’s development process but generally I
> would recommend to use a combination of linting, browser extensions, manual
> testing instructions – and CI tests.
> - If the accessibility team was to cover more than the Django admin, I
> think it would be worthwhile to also include accessibility of sites built
> with Django. Django is largely unopinionated about markup, but I remember
> its forms markup not being particularly good for screen readers, and the
> HTML code snippets in the docs would also be worth reviewing.
> - Same goes for admin docs – not too familiar with them myself so I’m not
> sure whether they are considered to be part of the admin, or separate.
> - I wouldn’t find it surprising if an audit of the Django admin turned up
> a lot of issues. IMHO part of the DEP should cover how to manage this –
> whether individual issues warrant individual tickets or not, and how to
> prioritize the issues if relevant. Which kinds of issues are likely to need
> design input. If the DEP is done first, also talk about what kind of
> auditing would be valuable, and how to make it happen.
>
> To help with the initial audit and prioritisation of issues, I would
> suggest to first start by creating a map of all of the parts of the Django
> admin that are to be audited – list all of the individual pages, and all of
> the states the pages can be in (success, error, loading – empty content /
> some content / paginating, etc). I also find it worthwhile to add a
> succinct definition of how each of those pages is likely to be used – for
> example things that are only configured once for a site’s lifetime are
> presumably not as 

Re: Admin accessibility

[Thibaud Colas]

Hi Tom,

It’s exciting to see this getting started! To me a DEP would be highly 
beneficial, because there is a lot to this that goes beyond finding and 
fixing individual issues – it’s more about detailing the a process for 
parts of Django to stay accessible over time. Here are things I’d suggest 
to cover, in addition to your list:

- Going further than the targeted standard and tests in CI –  outline clear 
steps developers should take when testing their work: using developer 
tools, screen readers, etc. It’s not practical to just state the standard 
as WCAG is quite big, and open to interpretation. And CI testing will never 
be enough to reach any degree of compliance.
  - I’m not familiar with Django’s development process but generally I 
would recommend to use a combination of linting, browser extensions, manual 
testing instructions – and CI tests.
- If the accessibility team was to cover more than the Django admin, I 
think it would be worthwhile to also include accessibility of sites built 
with Django. Django is largely unopinionated about markup, but I remember 
its forms markup not being particularly good for screen readers, and the 
HTML code snippets in the docs would also be worth reviewing.
- Same goes for admin docs – not too familiar with them myself so I’m not 
sure whether they are considered to be part of the admin, or separate.
- I wouldn’t find it surprising if an audit of the Django admin turned up a 
lot of issues. IMHO part of the DEP should cover how to manage this – 
whether individual issues warrant individual tickets or not, and how to 
prioritize the issues if relevant. Which kinds of issues are likely to need 
design input. If the DEP is done first, also talk about what kind of 
auditing would be valuable, and how to make it happen.

To help with the initial audit and prioritisation of issues, I would 
suggest to first start by creating a map of all of the parts of the Django 
admin that are to be audited – list all of the individual pages, and all of 
the states the pages can be in (success, error, loading – empty content / 
some content / paginating, etc). I also find it worthwhile to add a 
succinct definition of how each of those pages is likely to be used – for 
example things that are only configured once for a site’s lifetime are 
presumably not as worth improving as a screen a user would see on a daily 
basis. Here is an example in practice: 
https://docs.google.com/spreadsheets/d/1rTMilzKhcb43Y3fZKGJJeoKWLCR00bfgwVB9f6OaC2U/edit
 
.
 
This can also be used to track the auditing effort, and form the basis of 
an automated test suite for CI (or simply repeat testing).

Finally, consider ATAG2.0  (Authoring Tool 
Accessibility Guidelines) compliance additionally to WCAG. At a high level, 
ATAG is made of two parts:

- Part A: Make the authoring tool user interface accessible. That sounds 
like what we’re discussing here.
- Part B: Support the production of accessible content. That’s a whole 
other topic but feels relevant too.

ATAG is nowhere near as well known / established / easy to test for, but it 
feels very relevant to the Django admin in particular, and I’m sure there 
will at least be some useful bits to consider in its success criteria

Hope this helps!

Thibaud


On Monday, May 25, 2020 at 11:56:39 AM UTC+1, Tom Carrick wrote:
>
> Hi,
>
> Thanks for the feedback. I had thought about a DEP when I was writing up 
> the original post actually, I just wasn't sure what it should contain. Here 
> are my thoughts, based on the feedback so far:
>
> - Defining a standard to target.
> - Forming an a11y team that covers the django admin and all sites in the 
> django github organization, and defining its role, membership, etc.
> - Deciding on a CI process
> - An outline of current issues and how to solve them.
>
> If anyone can think of anything else, please let me know. If/when there's 
> a consensus I'll start writing a draft.
>
> Mariusz, I mentioned this in the original post, but 
> https://www.w3.org/WAI/policies/ has a good overview of laws and EU 
> directives in this area. From my browsing through, it seems that they all 
> either, have their own national standard, or are using WCAG 2.0/2.1 AA. 
> Since we probably don't want to define our own standard, I think AA is the 
> way to go. This seems to also be the recommendation I hear from people in 
> the accessibility field working on regular websites. AAA seems to be more 
> suited for very specialist sites that explicitly target disabled people.
>
> Most of AAA is completely feasible for us, but there are some reasons it 
> would be difficult:
>
> - All language needs to be at a lower secondary education level, or have 
> an alternative that is. This doesn't seem feasible, for e.g. the 
> documentation.
> - Users that are logged out need to be able to resume their session where 
> 

Re: Admin accessibility

[Tom Carrick]

Hi,

Thanks for the feedback. I had thought about a DEP when I was writing up
the original post actually, I just wasn't sure what it should contain. Here
are my thoughts, based on the feedback so far:

- Defining a standard to target.
- Forming an a11y team that covers the django admin and all sites in the
django github organization, and defining its role, membership, etc.
- Deciding on a CI process
- An outline of current issues and how to solve them.

If anyone can think of anything else, please let me know. If/when there's a
consensus I'll start writing a draft.

Mariusz, I mentioned this in the original post, but
https://www.w3.org/WAI/policies/ has a good overview of laws and EU
directives in this area. From my browsing through, it seems that they all
either, have their own national standard, or are using WCAG 2.0/2.1 AA.
Since we probably don't want to define our own standard, I think AA is the
way to go. This seems to also be the recommendation I hear from people in
the accessibility field working on regular websites. AAA seems to be more
suited for very specialist sites that explicitly target disabled people.

Most of AAA is completely feasible for us, but there are some reasons it
would be difficult:

- All language needs to be at a lower secondary education level, or have an
alternative that is. This doesn't seem feasible, for e.g. the documentation.
- Users that are logged out need to be able to resume their session where
they left off after logging in, with all form fields filled, etc.

There are others that are difficult, but I don't think any apply to us
currently.

Cheers,
Tom


On Mon, 25 May 2020 at 11:09, Mariusz Felisiak 
wrote:

> Hi Tobias,
>
>   I'm not a WCAG expert, and it's not clear to me what steps we would like
> to take. In the ticket we have only steps describes as *"very basics
> which should include"*, so I can imagine that's not all we need to do to
> be WCAG 2.1 compliant on AAA, AA or A level. As far as I'm concerned WCAG
> is quite massive. Moreover if we want to make changes in CI we should
> discussed available tools, etc. We can change colors but what next? We will
> be not able to guarantee that the contrast of all elements remains
> appropriate, we cannot do this manually.
>
> Best,
> Mariusz
>
> --
> 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/be97c4e7-f961-4d46-998f-693ca6076f09%40googlegroups.com
> 
> .
>

-- 
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%3DMaG5C7hHJ%3DJZaLZ8DNsevZzr8hmJ%3Dd4S%3D1mmTsXkiyPZw%40mail.gmail.com.

Re: Admin accessibility

[Mariusz Felisiak]

Hi Tobias,

  I'm not a WCAG expert, and it's not clear to me what steps we would like 
to take. In the ticket we have only steps describes as *"very basics which 
should include"*, so I can imagine that's not all we need to do to be WCAG 
2.1 compliant on AAA, AA or A level. As far as I'm concerned WCAG is quite 
massive. Moreover if we want to make changes in CI we should discussed 
available tools, etc. We can change colors but what next? We will be not 
able to guarantee that the contrast of all elements remains appropriate, we 
cannot do this manually.

Best,
Mariusz

-- 
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/be97c4e7-f961-4d46-998f-693ca6076f09%40googlegroups.com.

Re: Admin accessibility

[Tobias Bengfort]

Hi,

felixxm proposed in https://code.djangoproject.com/ticket/31617 to add a
DEP for this. The more I think about it, the less I agree.

There is no DEP for security, usability, developer ergonomics or
anything like that, so why should there be one for accessibility?

Like with any of the other categories, there are laws and regulations
that define a lower bound, but more is always better. And like with the
other categories, there are ways to find issues (think fuzzers) but no
way to verify the absence of issues.

So I think accessibility issues should be handled much like security
issues: When we find one, we fix it as quickly as possible. If there is
a conflict, say between security and accessibility, we decide on a
case-by-case basis.

Concerning which standard we should target: Tom made the case to target
WCAG 2.1 AA. I have not noticed any disagreement in this thread and
completely agree personally. Also note that many national regulations
are based on WCAG. So this question seems to be answered.

tobias

-- 
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/1a86d2d0-b3a2-0c56-8e13-cc64a32bead4%40posteo.de.

Re: Admin accessibility

[Thibaud Colas]

Hi all,

I’m also interested in helping with this, although I’ve never been involved 
with Django development before. I’ve recently worked on a similar accessibility 
effort for Wagtail , a CMS built 
upon Django, which largely replaces the Django admin interface on projects 
where it’s used – and thus has similar use cases and audiences. We 
discussed which standards to aim for, why, which tools to use when, what to 
expect of contributors, etc, which I believe would be similarly relevant to 
Django. If Django had done this before we’d definitely have borrowed from 
its approach :)

I would recommend Pa11y  as a tool to 
consider adding in CI. It uses HTML CodeSniffer and Axe under the hood 
(similarly to Lighthouse), which both score relatively well in how many 
issues they find. As Kye mentions this only goes so far (30-40% of issues 
at most ), but still 
helpful to have automated checks if possible.

Cheers,

Thibaud



On Tuesday, 19 May 2020 12:12:17 UTC+1, 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 

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 

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 

Re: Admin accessibility

[Kye Russell]

Hi all,

I am legally blind. Accessibility discussions tend to largely revolve
around contrast and screen readers (which I do not use) as it’s easy to
measure for (albeit poorly without actually trying to use a screen reader
yourself, which nobody tends to do).

I am unsure if I have any valuable / unique perspective to share, and I
probably don’t, but I am always happy to help. I have wanted an excuse to
get involved in the framework's development and this would be as good a
time as any.

The one thing I will say (and this doesn’t come from any lived experience,
rather what I’ve heard) is not to rely to heavily on automated
accessibility metrics, especially when it comes to screen reader
friendliness. An interface can tick all the automated boxes but still be
terrible to use. Just as with other user interfaces, automation can only
get us so far and additional manual checking would be worthwhile.

Kye




On 21 May 2020 at 9:33:51 pm, Tom Carrick (t...@carrick.eu) wrote:

Hi Adam,

> Which checker did you use?

I had a brief check with a few. Firefox's devtools, Lighthouse, and
WebAIM's WAVE browser extension. WAVE is quite nice in that it shows the
problems directly on the page, but they all give more or less the same
information. If Lighthouse can be integrated into the CI it seems the most
logical option. Lighthouse also gives a 0 - 100 score metric for each page,
which would be nice as part of a coverage-style CI process, i.e. the score
can remain the same or increase, but a decrease will fail the test.

> Would you be able to work on this on an ongoing basis? If you know others
who are interested, perhaps we could even form a Django a11y team, just
like we have an i18n team.

I'm happy to work on this on an ongoing basis. Thinking over the idea of an
a11y team, at first I thought it would have too narrow a scrope as it only
really concerns the admin, but I realised it also concerns the docs, the
djangoproject website, and other sites under the django org (django-people
and so on), so perhaps it's worth doing. That said, I don't have any
physical disabilities to speak of. My eyes are pretty bad, small text can
be a problem, but that's about it. It would be good to get some feedback
from people that this directly affects, but I don't know of many. It'd also
be hugely beneficial of course if any a11y team includes people with
physical disabilities or at least experience with it. I can only
immediately think of one person in the Django community that might fit, so
I will reach out to them and ask if they'd be interested in giving any
input here, but more voices would be useful.

For the low-hanging fruit, I will run Lighthouse on some more pages and
write some tickets up when I get some time, hopefully over the weekend.

Cheers,
Tom

On Thu, 21 May 2020 at 14:04, Adam Johnson  wrote:

> Hi Tom
>
> It's a laudable goal to make the admin accessible. Thank you for doing the
> research on currently laws and guidelines.
>
> I haven't audited the entire admin, but I have run a checker through some
>> pages.
>>
>
> Which checker did you use? I see Google's Lighthouse checks for many
> accessibility issues: https://web.dev/lighthouse-accessibility/
>
> I think fixing any "low hanging fruit" would be acceptable PR's right now.
>
> Setting a target and keeping to it would be harder though. Documentation
> is easy to write, but it can easily be forgotten/ignored, so I'd prefer a
> CI solution. One potential CI solution is running admin tests through the
> Lighthouse CLI.
>
> There will certainly add an ongoing maintenance cost. Would you be able to
> work on this on an ongoing basis? If you know others who are interested,
> perhaps we could even form a Django a11y team, just like we have an i18n
> team.
>
> On Tue, 19 May 2020 at 12:11, 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 

Re: Admin accessibility

[Tom Carrick]

Hi Adam,

> Which checker did you use?

I had a brief check with a few. Firefox's devtools, Lighthouse, and
WebAIM's WAVE browser extension. WAVE is quite nice in that it shows the
problems directly on the page, but they all give more or less the same
information. If Lighthouse can be integrated into the CI it seems the most
logical option. Lighthouse also gives a 0 - 100 score metric for each page,
which would be nice as part of a coverage-style CI process, i.e. the score
can remain the same or increase, but a decrease will fail the test.

> Would you be able to work on this on an ongoing basis? If you know others
who are interested, perhaps we could even form a Django a11y team, just
like we have an i18n team.

I'm happy to work on this on an ongoing basis. Thinking over the idea of an
a11y team, at first I thought it would have too narrow a scrope as it only
really concerns the admin, but I realised it also concerns the docs, the
djangoproject website, and other sites under the django org (django-people
and so on), so perhaps it's worth doing. That said, I don't have any
physical disabilities to speak of. My eyes are pretty bad, small text can
be a problem, but that's about it. It would be good to get some feedback
from people that this directly affects, but I don't know of many. It'd also
be hugely beneficial of course if any a11y team includes people with
physical disabilities or at least experience with it. I can only
immediately think of one person in the Django community that might fit, so
I will reach out to them and ask if they'd be interested in giving any
input here, but more voices would be useful.

For the low-hanging fruit, I will run Lighthouse on some more pages and
write some tickets up when I get some time, hopefully over the weekend.

Cheers,
Tom

On Thu, 21 May 2020 at 14:04, Adam Johnson  wrote:

> Hi Tom
>
> It's a laudable goal to make the admin accessible. Thank you for doing the
> research on currently laws and guidelines.
>
> I haven't audited the entire admin, but I have run a checker through some
>> pages.
>>
>
> Which checker did you use? I see Google's Lighthouse checks for many
> accessibility issues: https://web.dev/lighthouse-accessibility/
>
> I think fixing any "low hanging fruit" would be acceptable PR's right now.
>
> Setting a target and keeping to it would be harder though. Documentation
> is easy to write, but it can easily be forgotten/ignored, so I'd prefer a
> CI solution. One potential CI solution is running admin tests through the
> Lighthouse CLI.
>
> There will certainly add an ongoing maintenance cost. Would you be able to
> work on this on an ongoing basis? If you know others who are interested,
> perhaps we could even form a Django a11y team, just like we have an i18n
> team.
>
> On Tue, 19 May 2020 at 12:11, 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 

Re: Admin accessibility

[Adam Johnson]

Hi Tom

It's a laudable goal to make the admin accessible. Thank you for doing the
research on currently laws and guidelines.

I haven't audited the entire admin, but I have run a checker through some
> pages.
>

Which checker did you use? I see Google's Lighthouse checks for many
accessibility issues: https://web.dev/lighthouse-accessibility/

I think fixing any "low hanging fruit" would be acceptable PR's right now.

Setting a target and keeping to it would be harder though. Documentation is
easy to write, but it can easily be forgotten/ignored, so I'd prefer a CI
solution. One potential CI solution is running admin tests through the
Lighthouse CLI.

There will certainly add an ongoing maintenance cost. Would you be able to
work on this on an ongoing basis? If you know others who are interested,
perhaps we could even form a Django a11y team, just like we have an i18n
team.

On Tue, 19 May 2020 at 12:11, 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 

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: Admin accessibility tweaks

[Russell Keith-Magee]

On Thu, Feb 25, 2010 at 12:29 AM, Chris Adams  wrote:
> We've been collecting various tweaks to the stock Django 1.1.1 which
> have been requested by our 508 testers. I'd appreciate it if someone
> could review these tickets:
>
> Add scope=col to changelist table headers:
> http://code.djangoproject.com/ticket/12957
>
> Add alt text to SelectFilter2's filter widget:
>
> http://code.djangoproject.com/ticket/12959
>
> SelectFilter2 loses help_text - not a pure accessibility issue but it
> can cause confusion in some cases:
>
> http://code.djangoproject.com/ticket/6183
>
> Feedback on streamlining these reports is welcome - I don't think we
> have too much else but I'm still waiting for details about the issues
> reported on all of our projects.
>
> I'm tracking our changes here:
>
> http://github.com/acdha/django/commits/1.1.1-508-fixes

Thanks for that Chris. We're certainly interested in hearing in any
suggestions on how we can improve accessibility in Django's admin, or
in Django's toolset in general.

Keeping a clean branch of fixes is also very helpful - it means that
when one of the core team can find the time to dedicate to the
problem, there is a ready-to-use source of patches.

On a related note - there has been talk recently about doing a design
refresh on the admin. If you have some accessibility/508 experience,
you might want to keep an ear to the ground so you can participate in
any design discussions that occur when this happens.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Admin accessibility tweaks

[Chris Adams]

We've been collecting various tweaks to the stock Django 1.1.1 which
have been requested by our 508 testers. I'd appreciate it if someone
could review these tickets:

Add scope=col to changelist table headers:
http://code.djangoproject.com/ticket/12957

Add alt text to SelectFilter2's filter widget:

http://code.djangoproject.com/ticket/12959

SelectFilter2 loses help_text - not a pure accessibility issue but it
can cause confusion in some cases:

http://code.djangoproject.com/ticket/6183

Feedback on streamlining these reports is welcome - I don't think we
have too much else but I'm still waiting for details about the issues
reported on all of our projects.

I'm tracking our changes here:

http://github.com/acdha/django/commits/1.1.1-508-fixes

Thanks,
Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.