티스토리 수익 글 보기
If you want to help,
- Try out their static admin demo with the new shortcuts.
- Or install django-admin-keyshortcuts on your project and try it out there.
Then come back here and let us know what you think!
8 posts – 3 participants
]]>Issues:
- The links doesn’t indicate what they do (at least when looking at them) and are also not accessible when using screen readers.
- And as the number of links in the hierarchy increases the hierarchy becomes longer.
Solutions:
For the links as they don’t indicate what they do, so here are some suggestions:
-
Add a label to indicate what the links would do something like below, but we need to pick what is the exact wording and styling to put in the label. (suggested by @sarahboyce) in django.contrib.admin.templates.admin.date_hierarchy.html
<nav class="toplinks" aria-labelledby="date-hierarchy-label"> <span id="date-hierarchy-label"> {% blocktranslate %}Filter by {{ field_name }}{% endblocktranslate %} </span> -
Add a new heading like this (suggested by @Antoliny0919)
-
Do we need a drop-down menu in the date hierarchy if the links are too many?
So, I need some feedback or suggestions on how we approach this.
1 post – 1 participant
]]>What we need to consider here is that the filter panel can also become very long, and if the table has many rows, its height can become quite large as well.
For example, one issue with the current layout is when there are many rows.
When the table has many rows, you have to scroll down a lot to access the filter.
And if the filtered results are also numerous, you’d have to scroll down again to apply another filter.
If list_editable is enabled and there are tall columns like TextField or DateTimeField in list_display, this issue can become even more pronounced.
I believe the current layout structure is not ideal from a UX perspective.
(I’ve created an issue regarding this.)
I have submitted a PR(Although the tests have not been added yet, I believe this is enough to clearly show what I have in mind.) to address this issue.
The solution I came up with is as follows.
The filter panel is provided fixed at the bottom.
Since both the filter panel and the table can become long, I thought it would be better to provide the panel in a floating state rather than a static one.
However, this approach has the drawback of covering part of the screen.
When placed on the left or right side, it would cover table columns on mobile-sized screens, which is not ideal.
Therefore, I decided that placing it at the bottom, covering table rows instead, would be a better choice.
However, since the filter itself takes up about 40% of the screen height, it can naturally cause inconvenience for users on small screens like mobile devices.
Especially in situations where the filter is not needed.
Therefore, the filter is provided with a toggle so that users can use it only when necessary.
On
Off
I need feedback from many people 
If you have any good ideas, please leave your comments on the PR or here!
1 post – 1 participant
]]>
Note that this is something that will improve over time. Thank you to all who contributed to this guide 
7 posts – 3 participants
]]>Feedback very welcome! Thank you to the Django @accessibility team for working on this, with input and support from @benjaoming, @frankwiles, @CodenameTim, and @Afi!
3 posts – 3 participants
]]>Currently, django.shortcuts.get_object_or_404() raises a hardcoded 404 message when an object is not found. Customizing this message requires wrapping it in a try/except, which adds unnecessary repetition and breaks the DRY principle.
Proposal:
Introduce an optional msg parameter to get_object_or_404(), allowing custom 404 messages:
obj = get_object_or_404(MyModel, pk=some_id, msg="Custom not found message")
This change would:
- Enable custom error messages without needing
try/exceptblocks. - Be backwards-compatible, defaulting to the current behavior if
msgis not provided. - Align with Django’s other customizable exceptions (e.g.,
ValidationError,PermissionDenied).
Justification:
- Reduces repetitive code in views and APIs.
- Enhances flexibility for more meaningful 404 messages.
- Keeps Django’s philosophy of offering customizable error handling.
Request for Community Feedback:
Would love to hear thoughts from the community on whether this change would be useful, or if there are other considerations we should take into account before moving forward with a PR.
4 posts – 3 participants
]]>Here’s the diagram:
We already have a pull request done to address basic legibility improvements: making the diagram bigger, and improving the color contrast of text: #18710. There are a number of remaining things I think might warrant other tweaks.
Image of text
Are there parts of the diagram we could convert as text content on the page? So we avoid showing the text within an image where it can’t be resized or customized.
Alt text
The current alt text, Django's ticket triage workflow, would be a good title but it’s not really a suitable alternative for the text within the image. Per WCAG SC 1.1.1 Non-text content, we need:
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose
So my question is – does the other content further down the page qualify as this text alternative? If so – is there a need to programmatically associate it with the image.
Colors perception
The diagram makes heavy use of colors to distinguish different states, which will be an issue for colorblind contributors.
My recommendation there would be to make minimal changes to keep things simple?
- Add a
stroke-dasharray="4"to the Mergers arrows - Turn the “completed” green into a shade with different luminance.
Demo with the “status” fill set to hsl(120 100% 68% / 1) / #5cff5c (combined with 30% opacity) to simplify comparison, with a preview of the grayscale result:
2 posts – 2 participants
]]>Would this solution also be acceptable from an accessibility standpoint? Maybe @thibaudcolas ?
6 posts – 2 participants
]]>
. There are multiple possible solutions, and we could use feedback to decide on how to prioritise them.
The problem
Admin UI components currently use the HTML title attribute to provide contextual help. For example here’s the help text to know what “Available groups” and “Chosen groups” are for / how the UI works, on my static demo of the user editing form:
First tooltip text: This is the list of available groups. You may choose some by selecting them in the box below and then clicking the “Choose” arrow between the two boxes.
For keyboard, voice recognition, and touch screen users – there is no way to access the information in the title attribute. For mouse users, it requires quite precise hand movements. Here it’s ok, but in other scenarios there isn’t always enough of a cue those tooltips are available.
The bottom line is – any use of the title attribute to provide contextual help for UI components needs a rethink.
Solutions
There are a lot of possible solutions here. We don’t have to pick just the one, we can apply a different solution in different scenarios. Here are all the different design / user experience options I could think of in order of UX complexity.
Always-visible text
This is probably the simplest as far as fixing accessibility issues: move the information from the tooltips to text directly on the page, placed where appropriate. This can either replace the text or icon of the element the tooltip is on, or be positioned next to it. However most of the admin UI hasn’t been designed for widespread use of visible runs of text like this, so this would compromise on the UI’s current information density.
So this would be a great simple fix in some scenarios – and elsewhere, would be the toughest change from a design perspective – we’d potentially need to adjust the UI quite a bit to make space for this approach.
Toggle-able text
The disclosure (show/hide) pattern is a good way to display help content inline, without changing the designs as much. There would be an always-visible toggle next to the UI, and upon clicking the toggle, the information would be revealed, pushing the rest of the page down (no overlay).
Tooltip text
We’d keep the tooltip pattern, but redesign and rebuild it with accessibility considerations in mind. I think this would be the simplest change because the design wouldn’t need reinventing as much. The technical implementation would be more complex than always-visible or toggle-able text, but still reasonable.
No text
Yup. In some scenarios – we could decide to just remove the tooltip text.
Separate documentation
Finally I think it’s worth keeping in mind the point of those tooltips is to help users understand the UI. Separate documentation could do this as well, with textual descriptions and annotated screenshots. This could be within the admin still, in admindocs, or be a separate website like the developer documentation.
Other problematic tooltips
Here are other examples so people get a sense of which approach might work where.
Changelist bulk actions
On my demo changelist, there’s a tooltip on the “Go” button that says “Run the selected action”:
Changelist row sort order
Here’s another example, with a users changelist, where the user can control the order of the items with sorting controls (here, “Toggle sorting” as a tooltip on the up caret):
There are a lot of accessibility and general usability issues with this UI element, but at least as far as label it’s really problematic that keyboard / speech recognition / touch users can’t ever know what the button is for.
Related widget’s icon-only buttons/links
This example can be seen on a Change redirect form. Here, the title serves as label for an icon-only button / link.
What next
From all of this, my personal recommendation would be to go ahead with building a new tooltip component for the admin. Though there are other options, it feels like a pattern that would work well for the admin in the long run. We’d be able to replace all existing use of title with it. Either once that’s done or as part of the process, if people deem it appropriate, we could do the more complex redesign case by case when other patterns could work better.
For now – @erosselli is interested in working on this, so we’d appreciate any feedback on how best to take this forward.
7 posts – 4 participants
]]> The team has been up and running for three years, and is now looking for new members. With a lot happening in this space, we thought we were overdue for an update on what we’re up to.
Read our annual report on the website: Django accessibility in 2023 and beyond.
And for people interested in joining the team – please let us know here, or via DMs, in #accessibility on the Django Discord.
3 posts – 3 participants
]]>Please have a look at this UX issue: [Issue #35137](https://code.djangoproject.com/ticket/35137)
I already made some suggestions on how to improve the accessibility.
What do you think? What would be a good approach?
Cheers
Denis
18 posts – 5 participants
]]>I’ve created a PR for the addition of keyboard save shortcuts on the django admin. I’ve created a PR, but it’s be suggested that I open some discussion here about the new feature.
The PR with a detailed technical description can be found here.
Some starters on these as suggested by @thibaudcolas :
- Which actions should have shortcuts, based on frequency of use, availability in other similar tools.
- What key combinations should be used. Based on consistency with other tools.
- How we could make those shortcuts discoverable by end users (for example, in GitHub on macOS I can press Shift + ? to view a list)
Antidotally, I’ve had this feature in my stack for a while now and it’s been a really nice power user feature.
6 posts – 4 participants
]]>
the Django accessibility team (currently @tom, @sabderemane, @thibaudcolas) is switching to having regular meetings. As part of this switch, we’ll also start publishing our meeting notes, in this thread.
If you want to be aware when there are new meeting notes available, Discourse has per-thread “Watching” and “Tracking” modes which you can find at the very bottom of this page. You can also set this to “Muted” if you want.
Accessibility activities
If you’re wondering what we’re up to, aside from this thread, check out:
- Tickets tagged “accessibility” on Django’s Trac bug tracker
- django accessibility improvements project board in GitHub Projects
- DEP 11: Accessibility team, setting up the team and defining how it operates.
How to get involved
If you want to be involved with accessibility discussions, there are a lot of options:
- Join the Django Discord server, where we have a very active #accessibility channel.
- Use Django Internals > Accessibility, our dedicated forum category
- Consider joining our team! We don’t have a clear process yet, come say hi on Discord or in DMs.
31 posts – 5 participants
]]>1 post – 1 participant
]]> Django’s accessibility team is looking for feedback on proposed guidelines for contributors: Accessibility guidelines for all contributors #17338 (read the guidelines as HTML).
Django’s accessibility currently leaves a lot to be desired. It’s crucial for us to introduce those guidelines, and crucial for the guidelines to be strict enough to allow us to improve, while not being an unfair burden for contributors working on UI changes, which is challenging enough as it is. We need feedback from people with different perspectives to make sure this will work for everyone.
How you can help
Two ways!
- Read the guidelines on the preview page or on pull request #17338. Provide your feedback here or in GitHub – both “general sentiment” comments and specific issues / possible improvements are very welcome.
- Share this forum thread or my tweet about this with your colleagues, friends, enemies so they provide feedback as well. Have them sign up to the forum to reply here, or provide their feedback on the PR.
We’re looking for feedback from all contributors, in particular new contributors and people who could see themselves contributing in the future. We also want feedback from @steering_council members, who have a formal mandate to oversee the quality of Django.
Why we need those guidelines
Lots of reasons. Formally, the introduction of those guidelines is as per DEP-11. Excerpt from the team’s responsibilities:
- Deciding on any relevant accessibility guidelines to follow, such as WCAG, and at which conformance level. […]
- Coordinating […] the improvement of the accessibility in general in Django and associated projects. […]
- Writing and maintaining documentation relating to accessibility, such as a statement of commitment to accessibility issues, and contribution guidelines.
2 posts – 1 participant
]]>