Hey all.
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
Hey all.
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
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.
Hay!
I wrote this quick prototype to discuss the implementation.
Click to Expand
and there is an accordion style +
at the right end of the errorClick 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) {
e.style.display = e.style.display == "none" ? "block" : "none";
e.classList.toggle("active");
} else if (i == arguments.length - 2) {
e.classList.toggle("active");
} 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 ol.active li:hover::after{ /* #######ADDED###################### */
content: "Click to Collapse";
}
and
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
Behaviour:
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
Hi.
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.
(Discord)
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?
Hello.
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.
Cheers
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
Thanks @abhijeet-singh.
What do the other guys from DSF and the accessibility team think? (e.g. @thibaudcolas)
Sorry - I have been following this but didn’t notice the recent replies. I will try to have a look at the PR soon.
No worries and thank you
Hey @tom. Do you know when you will have time to look into this?
@denisiko I won’t find the time in the coming weeks so I’ve asked someone else from the team to take a look. Hopefully it doesn’t take too long.
Okay thank you @tom.