Skip to content

Commit

Permalink
Merge pull request #115 from matuzo/ericwbailey-patch-5
Browse files Browse the repository at this point in the history
[Eric review] #12
  • Loading branch information
matuzo authored Nov 2, 2023
2 parents a589a35 + 89a45b9 commit eb5fd83
Showing 1 changed file with 62 additions and 1 deletion.
63 changes: 62 additions & 1 deletion hell/adventcalendar/2023/12.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,12 +16,21 @@ active: true
intro: "<p>It's easy to get caught up in fixing less important things. Like arguing about how the screen reader really should be reading things while all of our buttons are still marked up as spans with an onClick event.</p>"
status:
review_manuel: "done"
review_eric: "open"
review_eric: "done"
review_saptak: "open"
---

<!-- Eric: I really enjoyed reading this, and thank you for writing it. A few tweaks and I think it'll be golden. -->

When it comes to speaking, writing, and teaching people about accessibility it bothers me when it's all about rules, restrictions, and judgment. In the first draft of this, I was writing to an imaginary colleague. When I read what I had written I realized that it was exactly the opposite of what I wanted it to be. It was full of judgment, rules, and restrictions. But I still felt like there were some good things here and if I could just remove the negativity then this could be useful to someone. Hopefully.

<!--
Eric:
>When it comes to speaking, writing, and teaching people about accessibility it bothers me when it's all about rules, restrictions, and judgment.
I might suggest a rephrase to put the main point first:
It bothers me when it's all about rules, restrictions, and judgment when it comes to speaking, writing, and teaching people about accessibility.
-->

<blockquote>So I don't like how the screen reader reads these numbers and I've been experimenting with different kinds of markup to get it to read better, like injecting spans to force it to make proper pauses…</blockquote>

<blockquote>I think the section element is a better fit than the article here but if we change these, then, of course, we need to update the class names in the CSS since it would be weird if it says article when it's a section…</blockquote>
Expand All @@ -41,33 +50,85 @@ I'm very much guilty of everything mentioned here so I decided that instead of a
3. So, do I understand correctly that you wrote something, then you read it, you didn't like it because it was too negative, but there was good advice in it, so you decided to use that instead and make it the topic of the post? If yes, please make it a bit more obvious in the intro.
Maybe I'm just confused because I didn't know what Swallowing camels means, so I had to figure out what the article is about while I was reading it.-->

<!--
Eric:
>I'm very much guilty of everything mentioned here so I decided that instead of an imaginary colleague, I would write this to myself.
Another slight suggestion to tweak this to be a little clearer:
I'm very much guilty of everything mentioned here. Because of that, I decided to write about past things I have done. No need to invent an imaginary colleague to help make things better.
-->

## The biggest problem

Instead of starting with the first issue I come across, I think a good idea is to start looking into the core functionality. Are there any issues there? If yes, I need to fix them first. But what is the core functionality?

<!-- Manuel:
About what kind of scenario are we talking here? an audit? a code review? -->

<!--
Eric:
>Instead of starting with the first issue I come across
What kind of issue? Accessibility? Performance? Usability? Something else? It might be helpful to explicitly state.
>Are there any issues there?
What kind of issues?
-->

Well, if I'm selling things then the core functionality is probably people being able to buy things. But if I'm trying to get a specific screen reader to read the prices in a way that I like better, and my checkout is broken because no proper form labels are making it impossible for some people to fill in their addresses. Then yes, I'm working on the wrong thing. In other words, I'm straining mosquitoes from my drink while swallowing camels.

<!-- Manuel:
link "swallowing camels" here instead or link it here as well -->

<!--
Eric:
>But if I'm trying to get a specific screen reader to read the prices in a way that I like better, and my checkout is broken because no proper form labels are making it impossible for some people to fill in their addresses.
This sentence feels like a run-on sentence to me. Can we break it into two separate ones?
-->

<!--
Eric:
>Then yes, I'm working on the wrong thing. In other words, I'm straining mosquitoes from my drink while swallowing camels.
Ah, I get it now. +1 to Manuel's suggestion of linking to the phrase the first time it's mentioned.
I might also suggest that you restructre the intro to tease this thought to better prime the reader for the concept this post deals with: Working on the wrong thing.
-->

## 100% accessible

I've always wanted to make the websites I'm working on perfect. But there is no such thing. Especially when it comes to accessibility. Websites are either more accessible or less accessible. They are never a 100% accessible.

<!--
Eric:
>They are never a 100% accessible.
Why?
-->

If my core functionality has big issues then my website is less accessible. Trying to fix it all and I will probably end up just fixing a few of the not-so-important things. If I want to move fast towards being more accessible I need to focus on fixing the core issues. There needs to be priorities.

<!--
Eric:
>Trying to fix it all and I will probably end up just fixing a few of the not-so-important things.
This is a really solid point. Love it.
-->

## It's not about me

As a developer, it's so easy to have a so-called "definition-of-done" where things work properly when I test it on my computer. I know there are other devices and other ways of using the web but I constantly need to remind myself of this. It is really easy to get caught up in details like how a screen reader pronounces things. But it's probably not the most important thing for me to care about.

Yes, of course really bad pronunciation may be an indicator that something is missing. Maybe a proper language attribute? Or maybe that my screen reader is not set up properly?

The point is that I need to move away from my priorities and what I find annoying or interesting and consider what might be the biggest obstacle for other people.

<!--
Eric:
>consider what might be the biggest obstacle for other people
Another great thought. I might suggest bolding this.
-->

## Take a step back

So, if I find myself arguing whether an extra div makes it too tricky for people to apply custom CSS or if the short description list element might be better off as an unordered list then it might be good for me to take a step back, to check the core functionality, and make sure that I didn't just swallow another camel.

<!-- Eric: This is a run-on sentence. As the conclusion it will be really important to ensure that it reads well. I'd suggest breaking it into 3-4 sentences to do so. -->


P.S. If ”swallowing a camel” is unfamiliar you can [read about the expression at the Cambridge Dictionary Website](https://dictionary.cambridge.org/dictionary/english/strain-at-a-gnat-and-swallow-a-camel).

0 comments on commit eb5fd83

Please sign in to comment.