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 avoid
