Email or username:

Password:

Forgot your password?
Top-level
Adrian Cochrane

@zensaiyuki In the case of browsers, the question seems to have always been not whether to have configuration but who should be configuring these settings.

The standards now say that webdevs have ultimate say whilst browsers provide defaults. The problem though is that the defaults are no longer reasonable, and webdev's final say can't always be trusted for reasons you've described in other toots.

Fairly trivial to fix when I'm not worrying about breaking JS...

12 comments
Zen replied to Adrian

@alcinnz it is certainly possible and even easy to write webpages and even web apps that leave browser accessibility settings available and working. it’s an education problem though and if, i, for instance, wrote a guide on how to do it, everything in it would fly in the face currently fashionable practices, which seem to view accessibility as “old fashioned”

Zen replied to Zen

@alcinnz i am a huge fan of js, as you know. but it’s like salt. it shouldn’t be the main ingredient.

Adrian Cochrane replied to Zen

@zensaiyuki I'm very much not a JS fan, though I have to admit that it has it's uses. I think it's a security risk that's too complex for independant browser engines to implement.

But regardless of what I think of it in general, it's inappropriate to implement in my auditory & smart TV browser engines. It's I/O model doesn't line up with what I need, and it's a clearer message to tell webdevs to not rely on JS if you want to be accessible on these devices.

Zen replied to Adrian

@alcinnz i suppose the problem it solves is, if the html “document” actually represents the UI of some kind of application, it’s a bad experience to require a full page refresh for every meaningful interaction, especially form validation. forms are especially complicated for screen reader accessibility as well.

Zen replied to Zen

@alcinnz in the less extreme case, it kind of sucks to need to listen to all the menu options over and over again on every page navigation. thankfully most screen readers are smart enough to let you skip it, so long as the page is marked up correctly and includes a “skip to content” link.

Zen replied to Zen

@alcinnz but by and large it’s bad if your ui buttons arbitrarily shuffle around and disappear and reappear and move up and down the screen as you navigate

Adrian Cochrane replied to Zen

@zensaiyuki Rhapsode is amongst those screenreaders: <nav> is silenced & it automatically skips to <main>.

And UI buttons arbitrarily shuffling around is especially bad when navigating the page with a TV remote! I can't let it happen! Though I will be happy to allow partial page refreshes akin to Intercooler.js.

Adrian Cochrane replied to Adrian

@zensaiyuki Forms meanwhile are a very interesting design space for me!

I might struggle to verbalize some/many forms in the wild, but with some minor HTML extensions there's opportunity to build Alexa-level conversational UIs! Though not as many as some may think due to HTML5.

TVs meanwhile needs those forms rendered to their own menus.

In either case I have to seperate forms out into their own mode & disallow styling to make them function well in these mediums.

Zen replied to Adrian

@alcinnz the base html form language is pretty good at expressing semantically what the form is/wants. it’s even a great API definition language, even if the apis amit describes are boring and old fashioned. ideally stuff like css/javascript is only used to enhance the experience- the forms *should* work with javascript and css fully disabled. but as we all know, they typically don’t.

Zen replied to Zen

@alcinnz but, assuming they did, they fulful the promise of a self describing API. all a client needs to do is understand the html form and it can present any sort of UI it needs to, to fully interact with the api the form describes. it’s really under appreciated how great a design it is.

Adrian Cochrane replied to Zen

@zensaiyuki Absolutely! Now can I make it a reality?

The struggle ofcourse is the majority of forms which like to define their own widgets, there's no way I'll be able to handle that...

Zen replied to Adrian

@alcinnz there’s spambots that do. which of course is another factor working against you. many websites, in the effort to stop spambots, make it difficult to realise this vision on purpose.

Go Up