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: Making startproject's settings more 12-factor-y

[Javier Buzzi]

This makes sense, I have a project that has a lot of settings files that 
get activated depending on the value of DJANGO_SETTINGS_MODULE. The 
solution i outlined above takes your reservations under consideration, if 
you want to use it, great, if not also great -- its a supplement not a 
requirement.

- Buzzi

On Wednesday, June 24, 2020 at 5:24:35 PM UTC-4, Dan Davis wrote:
>
>  tMost of the world is not as seamless as heroku.  My DevOps won't give me 
> any more than a handful of environment variables.  I wanted something like 
> DATABASE_URL, but all I have is DJANGO_LOG_DIR and DJANGO_SETTINGS_MODULE, 
> and so I need many, many settings files. I think that happens a lot, and 
> maybe a common pattern.
>
> From a 12factor perspective, I would like to get it down to local settings 
> (development) and production settings - yet for a lot of users, DevOps is 
> not really supporting a full PaaS-like experience any way.
>
> So - all of this has to be optional, which seems to rule out making it 
> part of the starting project template.  For sure, I've got my personal 
> template, and work has an on-premise template and a Cloud template as well 
> - but the department of developers doesn't always use these.  I find 
> databases containing the tables for other projects, long after the models 
> and migrations are gone, indicating a start by copy mode.
>
> On Wed, Jun 24, 2020 at 1:35 PM Kit La Touche  > wrote:
>
>> Carlton—thanks very much for the feedback. Javier—likewise. In 
>> particular, the imagined API you describe above is very appealing to me: 
>> start with `from_env` and then if you learn more about this and want to, 
>> add in some `EnvFileLoader`.
>>
>> I want to make clear my motivation and agenda here: I have recently had 
>> some conversations with newer devs about their experiences with deployment 
>> of apps they're working on, and with a friend at Heroku about his informal 
>> research into the problems people have with the same. One recurring 
>> friction point (and this is not just on Heroku at all, to be clear) is that 
>> there are a number of things that people *don't know they need to 
>> configure* for a working deployment.
>>
>> There are four settings that are recurring particular gotchas that people 
>> miss: the secret key, debug, static files, and databases. Static files 
>> seems big and out of scope, databases seems adequately handled by 
>> dj-database-url for most cases, and if your case is more complex, you'll 
>> learn it, but the other two (secret key and debug) seemed easy enough to 
>> flag as "you probably need to configure these!" with this sort of change to 
>> settings. This would be a first step towards shortening the distance from 
>> `startproject` to a working deployment.
>>
>> Newer devs in particular have, based on my conversations and this 
>> friend's research, been unlikely to (a) know that there are different 
>> `startproject` templates, and (b) feel equipped to choose one, if they do 
>> know.
>>
>> My hope is to make the smallest possible change to just start us moving 
>> towards more clearly flagging, especially for newer devs, "these are things 
>> that will need additional configuration in order to move from 'works on my 
>> machine' to 'deployed'."
>>
>> Towards that end, I thought that adding a "you might want to get this 
>> from the env" helper would be a clear indication to a new dev that this is 
>> a matter to even consider. Adding other configuration-getting options like 
>> different secret-store file backends seems like a good next step.
>>
>> Thanks,
>>
>> --Kit
>>
>> On Wed, Jun 24, 2020 at 11:13 AM Javier Buzzi > > wrote:
>>
>>> I looked at the libs that do what we want:
>>>
>>> django-configurations - it looks like they use environment variables / 
>>> either via loading them from the environ or a key/value pair file. Having 
>>> classes inside the settings.py might be weird to people.. at the least very 
>>> different.
>>> confucius - very simplistic, only supports environ and is classed based, 
>>> similar to django-configurations.
>>> django-environ - supports env file and environ, non-class based.
>>> dynaconf - supports all kinds of loading options (toml, json, ini, 
>>> environ, .env +) non-class based.
>>>
>>> In my opinion, django-environ and dynaconf would be the easiest to sell 
>>> to the community, it would require the least changes/paradigm shifts from 
>>> how everyone is already using django.
>>>
>>> Personally, i would really like to see something like this inside my 
>>> settings.py:
>>>
>>> from django.conf import from_env  # using standard os.environ
>>>
>>> DEBUG = from_env.bool("DEBUG", default=False)
>>>
>>> DATABASES = {
>>> "default":  from_env.db("DATABASE_URL")  # crash if it cant find it
>>> }
>>>
>>> ...
>>>
>>> for more complex examples:
>>>
>>> from django.conf import EnvFileLoader
>>>
>>> from_env = EnvFileLoader("path/to/.secret")
>>>
>>> ...
>>>
>>> We can have how ever many loaders we want: toml, 

Re: Making startproject's settings more 12-factor-y

[Kit La Touche]

Those are valid concerns, and I want to especially come back to "all of
this has to be optional, which seems to rule out making it part of the
starting project template".

But first, I want to reiterate that what's vital to me (and this may be
only my concern, of course!) is that newer developers, especially folks
without an ops team and without ops experience, have a clearer path to
deployment. Partly this is selfish: I want Django to grow and flourish, and
I think that giving new folks a good experience with it their first time
will facilitate that. Folks with an ops team can already be assumed to have
people to talk with and work with to negotiate and understand their
particular deployment context.

So, in light of that, coming back to "has to be optional", I agree—I very
much agree. However, I think it also has to be *visible*. That was my
motivation for, in my proposed PR, including it in the default
`settings.py` template, but making sure defaults were set to the values
they would be without the addition of `from_env`. I'm not sure at all that
that's the best way, but that was my thought process! "Optional" means a
few things, and I think that there's a difference between "setting env vars
should be optional" and "using `from_env` should be optional" and "having
`from_env` ever be in your `settings.py` should be optional", and I'd love
to clarify which part of that spectrum most closely aligns to your intent.

Cheers,

--Kit

On Wed, Jun 24, 2020 at 3:24 PM Dan Davis  wrote:

>  tMost of the world is not as seamless as heroku.  My DevOps won't give me
> any more than a handful of environment variables.  I wanted something like
> DATABASE_URL, but all I have is DJANGO_LOG_DIR and DJANGO_SETTINGS_MODULE,
> and so I need many, many settings files. I think that happens a lot, and
> maybe a common pattern.
>
> From a 12factor perspective, I would like to get it down to local settings
> (development) and production settings - yet for a lot of users, DevOps is
> not really supporting a full PaaS-like experience any way.
>
> So - all of this has to be optional, which seems to rule out making it
> part of the starting project template.  For sure, I've got my personal
> template, and work has an on-premise template and a Cloud template as well
> - but the department of developers doesn't always use these.  I find
> databases containing the tables for other projects, long after the models
> and migrations are gone, indicating a start by copy mode.
>
> On Wed, Jun 24, 2020 at 1:35 PM Kit La Touche  wrote:
>
>> Carlton—thanks very much for the feedback. Javier—likewise. In
>> particular, the imagined API you describe above is very appealing to me:
>> start with `from_env` and then if you learn more about this and want to,
>> add in some `EnvFileLoader`.
>>
>> I want to make clear my motivation and agenda here: I have recently had
>> some conversations with newer devs about their experiences with deployment
>> of apps they're working on, and with a friend at Heroku about his informal
>> research into the problems people have with the same. One recurring
>> friction point (and this is not just on Heroku at all, to be clear) is that
>> there are a number of things that people *don't know they need to
>> configure* for a working deployment.
>>
>> There are four settings that are recurring particular gotchas that people
>> miss: the secret key, debug, static files, and databases. Static files
>> seems big and out of scope, databases seems adequately handled by
>> dj-database-url for most cases, and if your case is more complex, you'll
>> learn it, but the other two (secret key and debug) seemed easy enough to
>> flag as "you probably need to configure these!" with this sort of change to
>> settings. This would be a first step towards shortening the distance from
>> `startproject` to a working deployment.
>>
>> Newer devs in particular have, based on my conversations and this
>> friend's research, been unlikely to (a) know that there are different
>> `startproject` templates, and (b) feel equipped to choose one, if they do
>> know.
>>
>> My hope is to make the smallest possible change to just start us moving
>> towards more clearly flagging, especially for newer devs, "these are things
>> that will need additional configuration in order to move from 'works on my
>> machine' to 'deployed'."
>>
>> Towards that end, I thought that adding a "you might want to get this
>> from the env" helper would be a clear indication to a new dev that this is
>> a matter to even consider. Adding other configuration-getting options like
>> different secret-store file backends seems like a good next step.
>>
>> Thanks,
>>
>> --Kit
>>
>> On Wed, Jun 24, 2020 at 11:13 AM Javier Buzzi 
>> wrote:
>>
>>> I looked at the libs that do what we want:
>>>
>>> django-configurations - it looks like they use environment variables /
>>> either via loading them from the environ or a key/value pair file. Having
>>> classes inside the settings.py might be 

Re: Making startproject's settings more 12-factor-y

[Dan Davis]

 tMost of the world is not as seamless as heroku.  My DevOps won't give me
any more than a handful of environment variables.  I wanted something like
DATABASE_URL, but all I have is DJANGO_LOG_DIR and DJANGO_SETTINGS_MODULE,
and so I need many, many settings files. I think that happens a lot, and
maybe a common pattern.

>From a 12factor perspective, I would like to get it down to local settings
(development) and production settings - yet for a lot of users, DevOps is
not really supporting a full PaaS-like experience any way.

So - all of this has to be optional, which seems to rule out making it part
of the starting project template.  For sure, I've got my personal template,
and work has an on-premise template and a Cloud template as well - but the
department of developers doesn't always use these.  I find databases
containing the tables for other projects, long after the models and
migrations are gone, indicating a start by copy mode.

On Wed, Jun 24, 2020 at 1:35 PM Kit La Touche  wrote:

> Carlton—thanks very much for the feedback. Javier—likewise. In particular,
> the imagined API you describe above is very appealing to me: start with
> `from_env` and then if you learn more about this and want to, add in some
> `EnvFileLoader`.
>
> I want to make clear my motivation and agenda here: I have recently had
> some conversations with newer devs about their experiences with deployment
> of apps they're working on, and with a friend at Heroku about his informal
> research into the problems people have with the same. One recurring
> friction point (and this is not just on Heroku at all, to be clear) is that
> there are a number of things that people *don't know they need to
> configure* for a working deployment.
>
> There are four settings that are recurring particular gotchas that people
> miss: the secret key, debug, static files, and databases. Static files
> seems big and out of scope, databases seems adequately handled by
> dj-database-url for most cases, and if your case is more complex, you'll
> learn it, but the other two (secret key and debug) seemed easy enough to
> flag as "you probably need to configure these!" with this sort of change to
> settings. This would be a first step towards shortening the distance from
> `startproject` to a working deployment.
>
> Newer devs in particular have, based on my conversations and this friend's
> research, been unlikely to (a) know that there are different `startproject`
> templates, and (b) feel equipped to choose one, if they do know.
>
> My hope is to make the smallest possible change to just start us moving
> towards more clearly flagging, especially for newer devs, "these are things
> that will need additional configuration in order to move from 'works on my
> machine' to 'deployed'."
>
> Towards that end, I thought that adding a "you might want to get this from
> the env" helper would be a clear indication to a new dev that this is a
> matter to even consider. Adding other configuration-getting options like
> different secret-store file backends seems like a good next step.
>
> Thanks,
>
> --Kit
>
> On Wed, Jun 24, 2020 at 11:13 AM Javier Buzzi 
> wrote:
>
>> I looked at the libs that do what we want:
>>
>> django-configurations - it looks like they use environment variables /
>> either via loading them from the environ or a key/value pair file. Having
>> classes inside the settings.py might be weird to people.. at the least very
>> different.
>> confucius - very simplistic, only supports environ and is classed based,
>> similar to django-configurations.
>> django-environ - supports env file and environ, non-class based.
>> dynaconf - supports all kinds of loading options (toml, json, ini,
>> environ, .env +) non-class based.
>>
>> In my opinion, django-environ and dynaconf would be the easiest to sell
>> to the community, it would require the least changes/paradigm shifts from
>> how everyone is already using django.
>>
>> Personally, i would really like to see something like this inside my
>> settings.py:
>>
>> from django.conf import from_env  # using standard os.environ
>>
>> DEBUG = from_env.bool("DEBUG", default=False)
>>
>> DATABASES = {
>> "default":  from_env.db("DATABASE_URL")  # crash if it cant find it
>> }
>>
>> ...
>>
>> for more complex examples:
>>
>> from django.conf import EnvFileLoader
>>
>> from_env = EnvFileLoader("path/to/.secret")
>>
>> ...
>>
>> We can have how ever many loaders we want: toml, json, ini ..
>>
>> This is both borrowing heavily from dynaconf and django-environ, making
>> the fewest changes to how people are accustomed to doing things.
>>
>> .. what do you guys think?
>>
>> - Buzzi
>>
>> --
>> 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
>> 

Re: Making startproject's settings more 12-factor-y

[Kit La Touche]

Carlton—thanks very much for the feedback. Javier—likewise. In particular,
the imagined API you describe above is very appealing to me: start with
`from_env` and then if you learn more about this and want to, add in some
`EnvFileLoader`.

I want to make clear my motivation and agenda here: I have recently had
some conversations with newer devs about their experiences with deployment
of apps they're working on, and with a friend at Heroku about his informal
research into the problems people have with the same. One recurring
friction point (and this is not just on Heroku at all, to be clear) is that
there are a number of things that people *don't know they need to configure*
for a working deployment.

There are four settings that are recurring particular gotchas that people
miss: the secret key, debug, static files, and databases. Static files
seems big and out of scope, databases seems adequately handled by
dj-database-url for most cases, and if your case is more complex, you'll
learn it, but the other two (secret key and debug) seemed easy enough to
flag as "you probably need to configure these!" with this sort of change to
settings. This would be a first step towards shortening the distance from
`startproject` to a working deployment.

Newer devs in particular have, based on my conversations and this friend's
research, been unlikely to (a) know that there are different `startproject`
templates, and (b) feel equipped to choose one, if they do know.

My hope is to make the smallest possible change to just start us moving
towards more clearly flagging, especially for newer devs, "these are things
that will need additional configuration in order to move from 'works on my
machine' to 'deployed'."

Towards that end, I thought that adding a "you might want to get this from
the env" helper would be a clear indication to a new dev that this is a
matter to even consider. Adding other configuration-getting options like
different secret-store file backends seems like a good next step.

Thanks,

--Kit

On Wed, Jun 24, 2020 at 11:13 AM Javier Buzzi 
wrote:

> I looked at the libs that do what we want:
>
> django-configurations - it looks like they use environment variables /
> either via loading them from the environ or a key/value pair file. Having
> classes inside the settings.py might be weird to people.. at the least very
> different.
> confucius - very simplistic, only supports environ and is classed based,
> similar to django-configurations.
> django-environ - supports env file and environ, non-class based.
> dynaconf - supports all kinds of loading options (toml, json, ini,
> environ, .env +) non-class based.
>
> In my opinion, django-environ and dynaconf would be the easiest to sell to
> the community, it would require the least changes/paradigm shifts from how
> everyone is already using django.
>
> Personally, i would really like to see something like this inside my
> settings.py:
>
> from django.conf import from_env  # using standard os.environ
>
> DEBUG = from_env.bool("DEBUG", default=False)
>
> DATABASES = {
> "default":  from_env.db("DATABASE_URL")  # crash if it cant find it
> }
>
> ...
>
> for more complex examples:
>
> from django.conf import EnvFileLoader
>
> from_env = EnvFileLoader("path/to/.secret")
>
> ...
>
> We can have how ever many loaders we want: toml, json, ini ..
>
> This is both borrowing heavily from dynaconf and django-environ, making
> the fewest changes to how people are accustomed to doing things.
>
> .. what do you guys think?
>
> - Buzzi
>
> --
> 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/41cea044-ffe1-445d-ab7a-a65f69e6d85ao%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/CAFcS-hDn0AFW4dj_-secrMGq-iWYz-TWKG-vw9%3DVmZ3L6j04aA%40mail.gmail.com.

Re: Making startproject's settings more 12-factor-y

[Javier Buzzi]

I looked at the libs that do what we want:

django-configurations - it looks like they use environment variables / 
either via loading them from the environ or a key/value pair file. Having 
classes inside the settings.py might be weird to people.. at the least very 
different.
confucius - very simplistic, only supports environ and is classed based, 
similar to django-configurations.
django-environ - supports env file and environ, non-class based.
dynaconf - supports all kinds of loading options (toml, json, ini, environ, 
.env +) non-class based.

In my opinion, django-environ and dynaconf would be the easiest to sell to 
the community, it would require the least changes/paradigm shifts from how 
everyone is already using django.

Personally, i would really like to see something like this inside my 
settings.py:

from django.conf import from_env  # using standard os.environ

DEBUG = from_env.bool("DEBUG", default=False)

DATABASES = {
"default":  from_env.db("DATABASE_URL")  # crash if it cant find it
}

...

for more complex examples:

from django.conf import EnvFileLoader

from_env = EnvFileLoader("path/to/.secret")

...

We can have how ever many loaders we want: toml, json, ini .. 

This is both borrowing heavily from dynaconf and django-environ, making the 
fewest changes to how people are accustomed to doing things.

.. what do you guys think?

- Buzzi

-- 
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/41cea044-ffe1-445d-ab7a-a65f69e6d85ao%40googlegroups.com.

Re: Making startproject's settings more 12-factor-y

[Carlton Gibson]

There are plenty of project templates out there that offer more 
fully-featured starting points. It's generally agreed that's out-of-scope 
for the provided startproject template. 

But could we make it easier to use environment variables in the default 
template? That seems like a reasonable thing to discuss. 
Is it now time that Django brings this into the core? (In principle +1, yes)

So the PR  adds parsing of 
environment variable into the correct types, but we already have packages 
in the community doing that. 
The one that comes to mind is django-configurations (part of Jazzband) — 
and there's discussion there of moving the env parsing bit to depend on 
django-environ. 
Can we bring in the battletest code there, clearing up known niggles, 
rather that re-writing something from scratch? 

(I'm hoping folks from django-configurations might input here.) 

Kind Regards,

Carlton



-- 
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/2f1abd5f-3f42-4d69-b98a-55604ae4d888o%40googlegroups.com.

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: Fellow Reports - June 2020

[Mariusz Felisiak]

Week ending June 21, 2020.

Released Django 3.1b1.

*Triaged:*
https://code.djangoproject.com/ticket/31707 - django-ldap-auth-backend 
(invalid)
https://code.djangoproject.com/ticket/31702 - Support operator classes for 
unique indexes on PostgreSQL. (accepted)
https://code.djangoproject.com/ticket/31704 - django.test.runner breaks if 
ipdb or dependencies raise unexpected exceptions (wontfix)
https://code.djangoproject.com/ticket/31703 - Name all initial migrations 
"_initial". (accepted)
https://code.djangoproject.com/ticket/31709 - Support operator classes for 
exclusion constraints. (accepted)
https://code.djangoproject.com/ticket/31711 - WeekArchiveView seens to be 
zero based for week, instead of one based (wontfix)
https://code.djangoproject.com/ticket/31710 - Added all files validation to 
the "Uploading multiple files" example. (accepted)
https://code.djangoproject.com/ticket/31701 - Make FileDescriptor subclass 
DeferredAttribute. (accepted)
https://code.djangoproject.com/ticket/31712 - Inconsistent axes definition 
between PostGIS and Spatialite for 4326 (duplicate)
https://code.djangoproject.com/ticket/31713 - Adding srs parameter to 
GDALRaster.transform(). (accepted)
https://code.djangoproject.com/ticket/31670 - Change "whitelist" to "allow 
list" and "blacklist" to "deny list". (accepted)
https://code.djangoproject.com/ticket/22259 - Per row result for dumpdata 
(duplicate)
https://code.djangoproject.com/ticket/27399 - Segfault when running 
GDALBandTests on OSX 10.11.6 (needsinfo)
https://code.djangoproject.com/ticket/31718 - changepassword command should 
pass update_fields to user.save() (wontfix)
https://code.djangoproject.com/ticket/31727 - Open ID Connect Support 
(duplicate)
https://code.djangoproject.com/ticket/31723 - Lag() with DecimalField 
crashes on SQLite. (accepted)
https://code.djangoproject.com/ticket/31724 - django.urls.resolve ignores 
the FORCE_SCRIPT_NAME setting. (duplicate)
https://code.djangoproject.com/ticket/31729 - The documentation for 
ArchiveIndexView is not clear for new developers. (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/13064 - Fixed #31706 -- Removed 
unnecessary getattr() call in FileDescriptor.__get__().
https://github.com/django/django/pull/13053 - Fixed #31690 -- Added note 
about fuzzy entries in translation docs.
https://github.com/django/django/pull/13061 - Fixed #31696 -- Updated OWASP 
links in docs.
https://github.com/django/django/pull/13051 - Fixed #31689 -- Doc'd caveat 
about using bulk_create()'s ignore_conflicts on MySQL.
https://github.com/django/django/pull/13059 - Fixed #31702 -- Added support 
for PostgreSQL opclasses in UniqueConstraint.
https://github.com/django/django/pull/13067 - Fixed #31709 -- Added support 
for opclasses in ExclusionConstraint.
https://github.com/django/django/pull/13066 - Fixed #30472 -- Made 
Argon2PasswordHasher use Argon2id.
https://github.com/django/django/pull/12613 - Fixed #30583 -- Fixed 
handling JSONFields in XML serializer.
https://github.com/django/django/pull/13031 - Refs #31670 -- Removed 
whitelist/blacklist terminology in docs and comments.
https://github.com/django/django/pull/13077 - Fixed #31716 -- Fixed 
detection of console scripts in autoreloader on Windows.
https://github.com/django/django/pull/12979 - Fixed #6933 -- Added support 
for searching against quoted phrases in ModelAdmin.search_fields.
https://github.com/django/django/pull/13079 - Refs #31670 -- Renamed 
whitelist argument and attribute of EmailValidator.

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/3b96e790-16e7-4a94-81d3-ea858a3cf97ao%40googlegroups.com.