I have finished the first pass on my markdown previewer and was just looking for some feedback and advice for it. I plan to do a second pass on each project after finishing all five of the assignments in Front End Development Libraries, taking the feedback to improve each project.
I have used React for this project along with the Markdown, DOMPurify and React-Icons packages. I decided to write all the CSS myself instead of using Bootstrap for this project.
Below is the live version of my website:
If you would like to take a look at the source code:
Thanks in advance for taking a look.
This is a really nice job, one of the best I’ve seen in a while. Overall this is solid, so there isn’t a lot to critique here. Most of what I’m going to point out below is somewhat advanced accessibility issues and I certainly don’t expect you to know all of this. But since you’ve done such a nice job here you leave me no choice if I want to leave comments
Keyboard only functionality is very good but I think there is room for some improvement. In light mode, the focus outline on the editor window is basically the same color as the borders around it so it doesn’t stand out that much. You might think about making it a different color. The layout button on the editor window only shows the drop down menu on mouseover so I can’t choose different options with the keyboard.
The line number textarea is a concern. I don’t think this works well with screen readers. Since it is a separate element from the actual content in the editor the screen reader just reads through it, announcing each line number one at a time, without linking each line number to the content for the line. If you want to keep this the way it is then I think you need to hide the line numbers from assistive technology by using
aria-hidden="true" on that textarea and its related label. I’m also curious as to why you used a label and textarea for this? The bigger question here is whether line numbers are essential for the editor. If they are then you would want find an accessible way to incorporate them into the editor. I’ve never done this before so I don’t have a recommendation off the top of my head. My first thought would be to look at other online editors and see how they do it.
I think the preview div needs to have an accessible name so that when a screen reader user tabs into that div they know what they are tabbing into. You could do this by giving the Previewer h2 an id and then using
aria-labelledby="[id]" on the actual preview div. Also, because the previewer div may be longer than the browser height and thus need a vertical scroll bar (in other words, it overflows its parent container) you actually need to do some extra work to make sure keyboard users can Tab into it. Only Firefox does this properly at the moment. The other browsers will not allow the keyboard user to Tab into the div if there is a vertical scroll bar caused by overflow (unless there is some other focusable content in the div) and thus a keyboard only user wouldn’t be able to scroll the content in the div. I believe the other browsers are working on fixing this but sometimes these things take a while. Links for more information on this problem:
Short note on improving usability of scrollable regions
Keyboard and Overflow
When the view port is very narrow you only allow one pane to be shown at a time. This is of course a design decision on your part but I can see where it would get a little tedious to have to keep clicking the icon in the upper right to switch between the editor and previewer. Did you consider putting them one on top of the other? You could also allow the pane height to be resized manually so that the user could determine how much of each they want showing in narrow view.
A few more issues for narrow view:
- The light/dark mode toggle spans the entire width of the page and thus clicking anywhere above the pane switches the mode. Personally, I think this is slightly annoying and the click target on the toggle should only be about as wide as the icon/toggle switch.
- I think the keyboard focus can be managed a little better when switching between the panes. Using the keyboard, when I am viewing the previewer pane and click to switch to the editor the focus is placed after the editor pane and I have to shift+Tab to get back into the editor. When I’m viewing the editor pane and click to go to the previewer the focus is placed before the preview pane and then I can Tab to the copy button on the preview pane. In both cases, there is no visual indicator as to what happened to the keyboard focus. I would make sure the focus is set consistently between pane switches. Perhaps you set it on the pane itself, or leave it on the switch icon? Whichever you decide it should behave the same for both switches.
As I said, this is very nicely done and I am just pointing out some more advanced issues because you didn’t really leave me a lot to talk about.
Thanks for the feedback, it gives me a good number of issues to tackle on my second pass.
I agree with the outline of the editor. It blends in too easily and would benefit from a highly contrasting color or some more obvious effect. I didn’t catch the layout button not opening with keyboard at all, so thanks for that, added it to my list of bugs to fix.
The line numbers is a feature that I personally wanted to add to this project. I have seen markdown editors with them but also a lot without.
- The reason why I chose to use two textarea elements to emulate an editor with line numbers is for two reasons.
- The project tests require the editor to be a textarea and thus I had to find a way to add line numbers to a textarea element.
- I am considering giving the user the ability to adjust font size for the editor and by having two text-areas I can apply this change easily, whilst making sure that the two elements don’t de sync.
- The most common suggestion for line numbers in a textarea was to use a background image with line numbers for the element. However most users reported it easily de syncing causes line number not to match inline with the text.
- The label for the line numbers element was an oversight. I was trying to tick off the errors showing up in Firefox Accessibility Issues Tool.
- I will probably implement the
aria-hidden="true" as I do wish the keep the feature for now. However I do not think this implementation is the best and if it was not for the need to use a textarea for the project test I would not implement it this way and maybe look into painting the numbers directly onto the element if that is possible?
I did not consider the preview div being a problem for screen readers. I also had no idea about
aria-labelledby="[id]" so that is great. Something new learned
I will look into the ability to scroll the previewer with the keyboard. I must admit Firefox is my main browser. So this brings attention to me to test more thoroughly in other browsers.
Stacking the two panels on top of each other in a narrow viewport is indeed something I had not considered. You are right, it would be best to give the user to choice to do either. This is a simple fix so it will definitely be fixed on the second pass.
- The ability to resize the editor/previewer width is the second feature I wanted to do along with the layout. I am currently looking into how to achieve this and hopefully will be able to implement it on my second pass.
Thanks for pointing out the light/dark toggle, that will be fixed.
I completely understand the inconsistency with focus when using a keyboard to interact with the panels. I will probably make it so that the switch button retains focus when switching.
Overall thank you for the detailed feedback. I have a lot of items to add to my list of things to address in my second pass
It also lets me know where some of my weaknesses lay at this time. Mainly the need to test more thoroughly with different browsers and interacting with the website using only keyboard, touch etc. One thing I am unsure about is how to go about testing with screen readers?
I hope my response doesn’t come across as trying to defend any of my design decisions. I truly do appreciate the time taken to look over the project.
If you are using Windows then NVDA is completely free and JAWS is quasi-free (it will only run for 40 minutes in free mode and then you have to restart your computer to get an additional 40 minutes). If you are on a mac then you should already have VoiceOver.
Screen readers take some getting used to but there are plenty of resources to help you learn how to test with them.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.