Usability of server error traceback collapsibles

Hey all.

Please have a look at this UX issue: [Issue #35137](

I already made some suggestions on how to improve the accessibility.

What do you think? What would be a good approach?


Maybe just me but when I see that little carot/arrow thingy by the box it tells me that it’s collapsible - also the box itself kind of suggests that it’s an accordian. If you’re looking for UI stuff maybe one thing to look at could be the accessibility of the error pages? I’ve seen some comments that accessibility improvements are much needed.

Hi, I would like to write a patch for this, but this is also my first patch and might need light guidance, would anyone point me in the general direction for writing a patch?
I have read the contribution guideline and now will be searching the code base for this.


I wrote this quick prototype to discuss the implementation.

Notable Additions :

  • Hovering over an error reveals a message Click to Expand and there is an accordion style + at the right end of the error
  • When Clicked it changes to Click to Collapse and the symbol at the right changes to the -.

On the code side, made some changes to the toggle function

  function toggle() {
    for (var i = 0; i < arguments.length; i++) {
      var e = document.getElementById(arguments[i]);
      if (e && i < arguments.length - 2) { = == "none" ? "block" : "none";
      } else if (i == arguments.length - 2) {
      } else if (i == arguments.length - 1) {
        e.textContent = e.textContent.trim() == "-" ? "+" : "-"; 
    return false;

and also added a couple of CSS rules handling the aesthetic side

  div.context ol li:hover::after{      /* #######ADDED###################### */
    content: "Click to Expand";
    position: absolute;
    background: white;
    color: black;
    padding: 5px;
    border: 1px solid #000;
    border-radius: 5px;
  div.context li:hover::after{      /* #######ADDED###################### */ 
    content: "Click to Collapse";


  div.context ol.context-line li span {       /* #######ADDED###################### */
    position: absolute;
    right: 56px;
    font-size: 30px;
    transform: translateY(-100%);

If this sounds alright then I own the ticket and then submit a patch.

Some changes made per the suggestions in the ticket tracker

When hovering a pointer over the button it will grow in size marginally and change colour (helping to indicate that its interactive)

@abhijeet-singh in the future please check discussions on tickets and whether someone else might be working on a task before creating a patch. From reading #35137, it seems clear to me @denisiko intended to work on this and put this forum thread together as part of working on a patch.

In my defence, the ticket was not assigned to anyone so I thought it might be ok to work on it , but you argument is perfectly valid too. I will ensure that this will not repeat in future

Thanks for pointing it out


I don’t mind if someone goes ahead with their suggestions or even their own patch. I was just under the impression that now was not the right time to already implement something but rather discuss certain problematic UX issues. That’s why I did not yet come up with a patch.

So what would be the best approach now? Should I write my own patch so there are at least 2 design alternatives to discuss? Or do we wait for feedback on usability and accessibility?

I wrote a patch for this and was suggested to use the <details> tag and this introduced some changes in the UI elements, I have created a Discord Thread to discuss this and also submitted and Code Pen, I would appreciate it if you checked it out and provided feedback.


Hay Again!
I was working on #35137 - Making Error Container Elements Interactive and I submitted a patch that involved me changing some of the JS code in the technical_500.html and was suggested to use <details> and <summary> tag citing its superior accessibility and less bloated code (effectively eliminating JS from the file and reducing CSS) and it turns out that there is no way to bi-bidirectionally expand the <details> tag ( expanding both forms below and above the tag ), so implementing it would result in major changes in the said UI element so I wanted to discuss its approach with the community before implementing the patch

Also, other places in the same file might use some refactoring using the <details> tag and possibly in other files too, if the community decided to refactor them, should it require its own ticket or submit a patch for them in the current ticket will do the job?


I think I solved the mentioned issues and came up with my own solution using HTML5 details/summary tags. Check out my Pull Request linked in the Django ticket for more info.

Having the elements positioned exactly like before required some additional JS. The end result however is now just like using built-in details/summary tags without JS and works by handling the attribute “open” on the summary node (plus the addition of a placeholder element for the inner error code line).

The accessibility issues are also solved now (“stepping” through the errors via tab/shift+tab and the enter key). Notice the E-Mail mode of the 500 debug page: It also works with the new changes and keeps the old layout to not falsely indicate interactivity.


Hay @denisiko
I prefer your approach as it looks similar to the original approach and would be much more familiar to the developers apart form that the test looks great too.
Great Work

1 Like

Thanks @abhijeet-singh.

What do the other guys from DSF and the accessibility team think? (e.g. @thibaudcolas)

1 Like

Sorry - I have been following this but didn’t notice the recent replies. I will try to have a look at the PR soon.

1 Like