351 karma · joined August 7, 2026
When I'm starting to go to bed, I usually take the dogs out one last time, go turn the lights off, etc.
When I'm starting a new team, that might mean selling execs on the idea that I need headcount, finding space for them to sit, etc. all of which are also getting ready.
> For one, getting ready means you have NOT started to do the thing.
Started and starting are very very different.
It's a pretty good litmus test for lack of empathy, ime.
There is no way to make a change to title attribute that isn't breaking to some use cases if you want it to support everything label/labelledby supports.
That said, if you are talking about tooltips, which are different from accessibility attributes, I digress. Tooltips have always been a software nightmare, and the web is no exception.
And the spec for the title attribute is for "advisory information", which isn't necessarily the same as descriptions. A title attribute could be used to give an image a credit, for example.
But the W3C recommends against relying on the title attribute for converting information:
* Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).*
You could argue that all the user agents across all mobile and desktop applications and browsers should present title information consistently even when there is no pointing device. But, that's unlikely to happen.
So you have a choice, leave out users with disabilities because "it's all the world's software that could change" or add a labelledby attribute and get on with one's day.
The title attribute may not be read by all screen readers by default, if at all. Some will, but some won't.
Additionally, when users are keyboard only, touch input, or using voice access they may not have an easy way to view the content contained by a title attribute. Whereas assistive technologies beyond screen readers can make use of it.
Users with fine motor impairment may be unable to hover long enough to show a title, depending on their browser.
Labelledby has the highest precedence in parsing, and every screen reader will know what to do with it. It removes uncertainty as a dev -- you know absolutely what will be read by it.
Aria labels can be used to give blind users the same experience as sighted users, which may not be the same text as a tooltip. If you need to convey something visual about the item being labeled and some text, you can use aria attributes to provide that.
Title gets inherited by all children, unless a child has an empty title. This could cause weird behaviors for screen reader users if one isn't careful. Labelledby is not inherited, and gives you control over which specific elements get labels.
Thank you for so succinctly and promptly demonstrating that point, even knowing my post was an obviously simplified example for the purpose of brevity.
I agree very much with the idea that we should be making the world better little by little, but better... better for who? Who benefits is a genuinely important question to answer. I believe "better for most", which means using our wealth to lift up many. Others believe "better for me" or "better for my tribe" or "better for my nation". The two styles are fundamentally at odds -- my "redistribute the wealth of billionaires" goal is just never going to square with "billionaires deserve their wealth".
So you have to answer "better for who" before you can efficiently climb "better" on your graph.
It's a single, very small addition to the code here. The element structure was already there, this was just signaling where to get the alt text for a button.
What about adding a single attribute is "horrible"? It seems concise, explicit, and DRY.
The idea that code can't be compelled to fit a shape by the government is goofball nonsense.
capitol.wa.gov is really informative and easy to use and looks nice.
Is three examples enough? You only asked for one. But I figured a few extra would help you.
It should just say fingerspelling. Conflating these two is like writing "Translates Shakespeare (Sonnet XC) into ..."
It's wonderful to try and experiment with this stuff, but it's very common for people to think fingerspelling is sign language.
Even the claim of fingerspelling is perhaps questionable. Deaf fingerspelling is a) MUCH faster and b) doesn't always spell every letter. It's not uncommon to, for example merge two letters together (I+L+Y), be moving some fingers up while others move down as in JULY or even skipping letters as in JUNE (which may omit the N). Words like SOON will be signed S-OO-N where the O is dragged out to the right. The longer you drag the O the more o's are implied. SOOOON vs SOON is a matter of how far the O is slid. And non-manual markers are a part of fingerspelling. SOON? Vs SOON are different eyebrow and eye shapes.
This very much feels like a student project, which I applaud. I'm assuming good intent here. It also feels like a young person knowing enough to be dangerous and furthering stereotypes and misconceptions unintentionally. I love the effort, but I'd encourage them to qualify the intent of the project quite a bit.
I really don't want to discourage this person. Please don't misunderstand me. I'm critical because this is cool. If it was garbage, I'd move on and not say anything. I just think that when building for a disability community, you have a responsibility to not over promise.
What your demo shows is a model understanding fingerspelling. Fingerspelling is ... a very small part of sign language.
To make the claim you are translating sign language you need to understand facial expressions, hand positioning/motion (help you vs help me, same hand shape, different positions/motions), classifiers, and a ton more stuff.
It's a really beautiful language, and I encourage everyone to learn it, but for your project I'd be very careful to not make a claim about translating sign language.
In the mean time, it sounds like you've got some passion for accessibility work? We're always looking for more skilled engineers to work in the a11y space. It does require some humility and willingness to listen to others needs.
I'm a PNW native, you don't need to tell me about the small sliver of old growth we still have in the Olympics.
Indigenous practices changed which trees grew, for instance the Gary oak was much more prevalent in areas they tended. But old growth was predominantly removed by settlers.
Or perhaps you get angry at people who call light utility vehicles "trucks"?
Language evolves. People accept colloquial definitions. Wait until you learn about pencil lead, koala bears, dry cleaning, and peanuts. Windmill is absolutely acceptable if it's understood by people to mean wind turbine, which it is.
So it might be correct to say that fires can be healthy for forests, but "supposed to" is more difficult to assert.
I just finished limbing, brush clearing, and preparing burn piles from a section of my forest because removing fuel is good, but most forests in America are young planted forests. They have smaller trees, less diversity, higher than typical density, and small trees that can cause fires to climb to crowns (where they then become deleterious rather than helpful.)
If we were to return to indigenous practices of regular burning, we would likely see healthier forests. But I'm not sure we'd see as much timber production from them. Since that's what most forests are held for... I don't see practices moving away from trying to maximize timber while minimizing cost any time soon.