티스토리 수익 글 보기

티스토리 수익 글 보기

Fixed #36367 — Improving the accessibility of the date_hierarchy layout in the admin. by XChaitanyaX · Pull Request #19688 · django/django · GitHub
Skip to content

Conversation

XChaitanyaX
Copy link

Trac ticket number

ticket-36367

Branch description

  • Added aria label to data-hierarchy navigation for better navigation when screen readers are used.

Checklist

  • This PR targets the main branch.
  • The commit message is written in past tense, mentions the ticket number, and ends with a period.
  • I have checked the “Has patch” ticket flag in the Trac system.
  • I have added or updated relevant tests.
  • I have added or updated relevant docs, including release notes if applicable.
  • I have attached screenshots in both light and dark modes for any UI changes.

@@ -1,5 +1,5 @@
{% if show %}
<nav class=toplinks>
<nav class=toplinks aria-label=Date hierarchy>
Copy link
Member

@Antoliny0919 Antoliny0919 Jul 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering translation and header navigation, I think it would be better to include an <h2> tag with visually-hidden inside and link it using aria-labelledby.

Copy link
Contributor

@sarahboyce sarahboyce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR 👍

I added some thoughts. The @django/accessibility team might be able to advise as to what would be the best approach

@@ -1,5 +1,5 @@
{% if show %}
<nav class=toplinks>
<nav class=toplinks aria-label=Date hierarchy>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to translate this, like the other nav aria-labels e.g. <nav aria-label="{% translate 'Breadcrumbs' %}">

I also think “Date hierarchy” is not the best label here, maybe “Filter by date” or “Filter by {field_name} date”
In order to make the title more descriptive, this could be determined within django.contrib.admin.templatetags.admin_list.date_hierarchy().

I also think if we create something descriptive, we may want to make this visible to all users rather than an aria-label. I don’t think it is clear to anyone what these do, especially if there are multiple date fields that could be being filtered

Finally, this will need a test to be accepted 😁

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello Sarah!
Personally, I feel that the word “hierarchy” should definitely be included, no matter what.
That’s because the links within the date hierarchy are structured in a hierarchical way.

I believe including that word could help users better understand the element when navigating through it.
Also, since it’s actually possible to filter by date using the sidebar filters as well,
I think it’s important to clearly distinguish between the two.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it’s good to add the field_name as well.
However, the real issue is that not only screen readers but also visual users cannot easily identify which field is being filtered.
Of course, we can see it from the query, but I have heard before that the admin page is no longer just a space used by developers.
This part definitely needs improvement.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I personally find “hierarchy” a bit odd, maybe “filter drill-down” 🤔
But I agree it’s not just a filter and so communicating that would be nice

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree as well.
Since there is a unique structure to the hierarchy, I think users need to understand that part.
Perhaps, as you mentioned an appropriate aria-labelledby would be necessary for that.

@XChaitanyaX
Copy link
Author

XChaitanyaX commented Jul 31, 2025

Thank you for reviewing,

I have some thoughts based on above comments

  • adding some text in the nav tag is very helpful (for visual users) as currently it has links which doesn’t say anything about what they do.
  • and btw the text “filter by release_date” in the image is just a place holder.

in django.contrib.admin.templates.admin.date_hierarchy.html

{% load i18n %}
{% if show %}
<nav class="toplinks" aria-labelledby="date-hierarchy-label">
<span id="date-hierarchy-label">
    {% blocktrans with field_name=field_name %}Filter by {{ field_name }}{% endblocktrans %}
</span> 
... remaining code

in django.contrib.admin.templatetags.admin_list.date_hierarchy() adding "field_name": field_name in return statements. It looks like the image below.
image

What do you guys think? 🤔

@sarahboyce
Copy link
Contributor

I think this is the right direction. We might play around with the wording and styling/layout but this kind of thing is what I had in mind 👍

Copy link
Member

@Antoliny0919 Antoliny0919 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for working on this ticket ⭐️

I like the structure you suggested.
This is just my personal opinion, but I think it would be better to structure the elements generated by the date hierarchy (links) and the tag used for the label function in a column layout.
my_date_hierarchy

The design aspect will probably need to be discussed with the accessibility team, but I created a simple example for reference.

Screenshot 2025-08-03 at 6 01 38 PM

And as sarah pointed out, I think testing will be necessary!

<nav class="toplinks">
<nav class="toplinks" aria-labelledby="date-hierarchy-label">
<span id="date-hierarchy-label">
{% blocktrans with field_name=field_name|title %} Filter by {{ field_name }} {% endblocktrans %}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using blocktranslate is better than blocktrans.
Also, since verbose_name is already intended to be human readable,
I’m not sure if the title filter is really necessary 🤔

</span>
{% block datehierarchytoplinks %}
{% block datehierarchyback %}
{% if back %}<a href="{{ back.link }}" class="date-back">&lsaquo; {{ back.title }}</a>{% endif %}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current link elements are made up of <a> tags.
I think using a ul/li structure would be more appropriate in terms of accessibility.

@Antoliny0919
Copy link
Member

Antoliny0919 commented Aug 3, 2025

++ If you always want to get your work reviewed, please don’t forget to switch the ticket flags to off 🙂

@XChaitanyaX
Copy link
Author

If there are more links in the hierarchy then wouldn’t it be better to put them in a drop-down menu? Any thoughts on this

@sarahboyce
Copy link
Contributor

If there are more links in the hierarchy then wouldn’t it be better to put them in a drop-down menu? Any thoughts on this

I’m happy with this idea being explored. The structure is a bit like a breadcrumb drilldown filter
Below is a rough example with filesystems
image
Having a breadcrumb format with dropdowns means that we keep the filter not taking up very much vertical space

I don’t know what the best solution is here. You might want to make a few suggestions with screenshots and start a discussion on the forum

@thibaudcolas
Copy link
Member

Static PR demo link – releases changelist. I will try to find time to test this / provide input on the forum later this week ⭐️

@thibaudcolas thibaudcolas moved this from New to To Review in django accessibility improvements Aug 27, 2025
@Antoliny0919
Copy link
Member

I’m happy with this idea being explored. The structure is a bit like a breadcrumb drilldown filter Below is a rough example with filesystems image Having a breadcrumb format with dropdowns means that we keep the filter not taking up very much vertical space

I don’t know what the best solution is here. You might want to make a few suggestions with screenshots and start a discussion on the forum

I like this proposal. Implementing it in a breadcrumbs format would definitely improve navigation for screen readers. However, this task would essentially require rebuilding the date hierarchy component. While it is indeed an accessibility improvement through structural changes, it feels like a rather large task for me. Would it be possible to categorize this work separately?

@XChaitanyaX
Copy link
Author

Any suggestions/feedback on the date hierarchy structure/remodelling please write them here.

@XChaitanyaX
Copy link
Author

I’m happy with this idea being explored. The structure is a bit like a breadcrumb drilldown filter Below is a rough example with filesystems image Having a breadcrumb format with dropdowns means that we keep the filter not taking up very much vertical space
I don’t know what the best solution is here. You might want to make a few suggestions with screenshots and start a discussion on the forum

I like this proposal. Implementing it in a breadcrumbs format would definitely improve navigation for screen readers. However, this task would essentially require rebuilding the date hierarchy component. While it is indeed an accessibility improvement through structural changes, it feels like a rather large task for me. Would it be possible to categorize this work separately?

date hierarchy itself is kind of very interesting to me, the purpose is like very limited (filtering by date), the more the unique dates, the messier it gets to sort via a particular date, not mentioning the need to select the month as well and of course the day itself.
I would rather format the way the date is displayed and search via ctrl + f in the browser.
idk, maybe it’s just me or I just don’t understand the concept of date hierarchy at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: To Review

Development

Successfully merging this pull request may close these issues.

4 participants