I think "front of the frontend" might not suit me well. I do love connecting the front of the frontend with the backend. Maybe I'm a back of the frontend girl? :)
=> More informations about this toot | More toots from lea@lea.lgbt
I still don't like to call myself "Full Stack Developer" or something. Maybe... just "web developer". I think that's just fine for me 💜
=> More informations about this toot | More toots from lea@lea.lgbt
It's maybe also due to frontend identity crisis. I think @elly wrote about it once :) I really don't (and can't) identify with what companies see as "frontend developer", which is a quite JavaScript-heavy role. JavaScript-heavy meaning: throwing megabytes of javascript onto a problem that could be solved with a couple lines of HTML and CSS. That's not me.
=> More informations about this toot | More toots from lea@lea.lgbt
Regarding front/back of the frontend, I love working with Vanilla JS. And I love HTML/CSS and try to keep the amount of JS small. Like using fetch instead of npm install axios. Like using native WebSocket APIs instead of pulling a library. Like using ES modules instead of Webpack. Like using Web Components instead of React. :)
However, I'm not strong in CSS, creating Design Systems or Accessibility. Regarding accessibility, I do my best, but I'm not an expert.
I think that's okay.
=> More informations about this toot | More toots from lea@lea.lgbt
Regarding accessibility in my everyday work, companies often see me as super strong, but I mostly just keep the 6 biggest failures from the webaim million report in mind when building things, which leads to companies seeing me as a accessibility super nerd 🙈
The biggest six are: bad contrast, missing alt text, missing labels, missing document language, buttons without text, links without text.
=> More informations about this toot | More toots from lea@lea.lgbt
PS here's the webaim million report. If you keep that in mind, you're already a hero ☺️
https://webaim.org/projects/million/
=> More informations about this toot | More toots from lea@lea.lgbt
But yeah, keeping those in top failures in mind (where most of them are even autofixable), would significantly improve the overall accessibility. Still, this won't assure you get an accessible thing in the end. So test your stuff with actual users, especially users with disabilities, and pay them adequately.
=> More informations about this toot | More toots from lea@lea.lgbt
@lea a hero, a rocket scientist and a Voodoo priest.
=> More informations about this toot | More toots from kprobiesch@mastodon.social
@lea Or, you know, just think for a bit longer before building stuff, and also how to simplify what you actually want to achieve.
Then it’s basically just following the standards and guidelines and for must things you don’t even need testing.
=> More informations about this toot | More toots from kc@chaos.social
@kc good point :)
=> More informations about this toot | More toots from lea@lea.lgbt
@kc sometimes they want you to build something fancy. Often so fancy it's against web standards. One bad example is building an on-screen virtual keyboard in a web page, instead of using a built-in virtual keyboard provided at OS-level. Or, building an accessibility overlay with an integrated screenreader inside a web page which interferes with OS-level screenreaders.
=> More informations about this toot | More toots from lea@lea.lgbt
@kc then, the best way to deal with that is to say no.
=> More informations about this toot | More toots from lea@lea.lgbt This content has been proxied by September (3851b).Proxy Information
text/gemini