Comment by arekkas | Hacker News Reader

Comment by arekkas | Hacker News Reader

Parent Full thread

The high CPU and memory usage was due to a large gif which was included two times. This gif accidentally was 1280p with 20fps and was about 40mb large. For some reason, the resizer did not properly work.

Anyways, the gif is now removed. I hope the performance gets much better now. The CPU fans on macbooks going up where probably due to a lack of a dedicated graphics card. This happened to me with my macbook and large gifs too.

If the problems don't go away, please create an issue in the repo so we can work on improving this! It would be important to include your steps so we are able to reproduce these issues.

edit://

Since this comment is on the top, I'll address a few more questions here too. If you missed the demo, it's here: http://editor.ory.am/

First, this is a layout editor first- and foremost. Behind the scenes, React, Redux and slate.js ( http://slatejs.org/ ) is being used. Each cell is a React component that you can implement yourself. In fact, the text component itself is a plugin that wraps slate.js.

Second, we're integrating this editor in Germany's largest e-learning platform (wiki-esque) with ~1 million MAUs: https://de.serlo.org

And lastly we're working on a business model behind it, with our ory sites product (early access): http://ory.am/sites/

If you want to check out our other open source products, feel free to do so: https://github.com/ory

This does not appear to work at all with my screen reader.

Accessibility as afterthought, as always.

I used to look forward to trying to help people fix their stuff to be accessible, but now I'm just tired of every single fucking thing somebody creates being broken for me because everything is a complete heaping pile of inaccessible garbage and nobody even thinks about accessibility. It's not like there aren't thousands of pages of documentation on how to make stuff accessible... but the libraries keep getting released without accessibility, and then people build components using several of these libraries and they're useless, and then people build entire apps out of these components... And the web that I used to know and love and get around just find goes dark.

And this is going to get integrated into some big educational site? So I guess it sucks to be a blind student in Germany.

What a mess.

Sorry for the negativity, but this just really, really gets old.

Sorry for the late reply, but this condemning tone just really, really gets old.

This is a frigging open source project. Take it or leave it. If you want something, you send a frigging patch. Or you ask nicely.

I read my comment again and realized that I could have been mistaken for being affiliated to the project. To be clear, I am not. I'm just one open source maintainer and contributor who gets upset when I (or other amazing people) put out work for free and then am somehow blamed for not doing this or that.

When literally the first sentence of the project description mentions an "accessible web", I think it's perfectly acceptable to have a condemning tone.

> ORY is a company building and maintaining developer tools for a safer, more accessible web.

The definition of "accessible" could be pretty broad. It doesn't have to mean what you have in mind. As I see it, is this WYSIWYG editor making the web more accessible to laypeople who don't know HTML, CSS, etc.? Definitely.

> The definition of "accessible" could be pretty broad.

Only if you are trying to play word games. Try googling that exact phrase - accessible web - and see if there are any results that support your point.

The tag line did not contain that exact phrase. It said "make the web accessible". Try googling "accessible definition"? Also, they seem to have since changed it to "easy to use", so the intention is clear. If you want to be offended by their use of the original meaning of "accessible", by all means.

EDIT: Okay I retract the "did not contain that exact phrase" part; I thought you were talking about their company's tag line. Anyway, feel free to be mad at the word choice.

It also says "Please Note: ORY Editor is pre-release" and while we're commited to improve the experience for everyone, this tone definitely doesn't motivate us.

It must really suck, and when I work on small(but large) personal projects I feel bad that someone might not be able to use it. What are some good resources to start thinking accessibility first? I remember in the past it was .. a project and a half in and of itself.

The nice thing is it's very easy to get started, and no matter what you're working on, be it a web project, a mobile app, or even something for desktop there are loads of resources out there, as well as people who care.

For web stuff, over the last month or so I've been pointing people to the relatively new but still pretty nice A11y Style Guide[0] This is obviously for just getting started. When we get into more complicated markup, I often find fantastic resources, articles, and examples from companies like SSB BART or Deque (no affiliation with either)

When mobile accessibility comes up, few people do it better than the BBC, and they have a great resource on it[1]

I'm also working on a playbook for mobile accessibility, but that's still under development.

The really important and kind of awesome thing is that it's extremely easier to test the accessibility of whatever you're building as you build it. Unlike the bad old days where screen readers costs $1,000 and no developers had access to them, on mobile or Mac screen readers are built directly into your device, and on Windows NVDA is completely free from [2]

Hope this gives you a starting point, and if you have more questions feel free to reach out, email in profile.

[0]: https://a11y-style-guide.com [1]http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mo... [2]https://NVAccess.org

I guess something I have trouble wrapping my head around is when is it acceptable to give up on a11y? I mean, it seems improbable to get a11y into an expansive CLI application. Or a 3D game. When does it become OK to give up?

> it seems improbable to get a11y into an expansive CLI application

Why? I used to use make menuconfig back in 2000--why should it not work now?

3d game? This I'll grant you. Some experiences are just not replicatable for the blind, though if you're interested in this at all check out the weird and wonderful world of audiogames and 3d audio with HRTF.

An editor? Even a visual editor? Is not one of these experiences. I used to use Visual Basic 6 just fine, dragging and dropping controls out of the toolbox, lining things up, and editing the code behind the widgets all the way back in 2002.

I see that this project apparently took 8 years by 150 people, according to the OP. With this much human effort behind it, it's remarkable that no one once said, hey, I wonder if anybody with a visual disability might want to use the app that this will be a part of?

I don't really understand your question. Mark what up, a command line interface? They don't really have markup.

If I'm trying to read a lot of data in a CLI, the output of top, for instance, I need to read by line with the screen reader fixed to a given column offset but it works fine even if it's a little awkward.

I guess I meant that in the case of HTML you usually mark things up with aria tags and what have you. Not that there was anything like that in CLI land.

How would you mark it up? If I have multiple panes with different data, and say a graph, how does a screen reader know that? As far as I know that kind of data can't be conveyed yet?

I really like the A11ycasts show by Google Chrome Developers https://www.youtube.com/playlist?list=PLNYkxOF6rcICWx0C9LVWW...

This is only one small facet of the problem, but a11y[0] is a helpful tool to automate accessibility testing. It of course doesn't cover everything you should be concerned about, but as someone who's far from an expert, it feels like a good starting point.

[0] https://github.com/addyosmani/a11y

Edit: Ahh I see you mentioned A11y or Ally, thought it was someone's user name.

Aside from using tab indexes to jump around on a page, what else helps?

Is Hacker News really good with accessibility?

Oh Screen Reader has that voice right? So proper use of Header tags... man how do you follow a chain of comments? control find and look for your user name? Oh maybe the threads part of Hacker News.

Aria tags...

Well probably good news for you with the move towards voice-interfaces with the Amazon Echo products and what not, maybe there will be API's or something to present data with voice-first in mind so no visual.

It doesn't work with your screen reader because the site is rendered after the initial page load. The content is not prerendered. However, the technology allows prerendering, so it actually works with screen readers. Some pieces might need improvement (e.g. missing alt tag on images at the moment).

By the way, blind students use the education platform, and they are really happy that such an amazing, ad-free platform exists.

As far as I know screenreaders can handle dynamic rendering just fine. Perhaps you just need to mark it as a live region? https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

This was something I really wish would be featured at every conference by device / OS manufacturers every year.

I was surprised there was no discussion of Android accessibility this year at IO.

So I take it you've never shipped an MVP?

A lot of us did and those worked perfectly with screen readers. It's not hard or even additional work, you just need to give a crap while doing basic design.

This is similar to the responsive/mobile design - if you care about it from the start, you'll structure the site/component in a way that it really won't take you much more time to support accessibility features. If you don't care at all, retrofitting accessibility will require severe refactoring and probably won't ever be done.

So not caring about it in "MVP" is about the worst thing you can do.

Not having something in the 'forefront' of one's mind isn't equivalent to "not caring".

You should also keep in mind that you're (implicitly) asking people to do more work – which is fine, but there are real costs and people aren't bad because they haven't already borne them.

No that is exactly my point - it's not "more work" if you think about it from the start. Just like it isn't more work to make a site responsive if you start correctly - but it's significantly more work when you have to rewrite a lot of components later because you didn't take accessibility (or responsiveness) in consideration at the start.

>it's not "more work" if you think about it from the start

Most of my job as a developer is thinking. So yes, it is more work. Accessibility / Responsiveness isn't always done first because it takes more time (either thinking or "working").

> Accessibility as afterthought, as always.

You are in a minority. Minorities are always an afterthought. It's hard meeting the needs of every single minority - there are so many with many diverse needs.

Yes, being in the small group that wants people to actually use proper accessible markup as WCAG indicates does put me in a minority, it's true.

However, this concept that there are a lot of minorities so obviously we can't cover all the bases seems a little silly. Do people of color need different markup? Do women require somebody adds special javascript libraries so they can access the content? Making content accessible to a screen reader is part of our job as web developers. Just like the site isn't done until it renders in IE 11, it's not done until it reads with NVDA. In fact, often times people can install an alternative browser, whereas it is currently impossible to install an alternative pair of eyeballs, so I would go so far as to advocate accessibility before heroic browser compatibility battles but obviously I'm biased here ;-)

>Just like the site isn't done until it renders in IE 11, it's not done until it reads with NVDA.

Interesting opinion. I'd argue that it's not at all a web developer's job to comply with every single accessibility guideline or support outdated browsers, unless required by their contract and paid for by whoever commissioned the work. These requirements are part of the reason that most governmental contracts are overpriced by a factor of 10 (the other reason being corruption).

It is unfortunate that the effort spent to accommodate screen readers is easy to see as less rewarding than the effort invested into all of the other users... Truthfully, it seems like the only really good solution would be to make screen readers much better at understanding the content than to make the content much better at being understood by screen readers. Pool the expertise where the need is. This kind of thing is why I feel that good AI is so important. We can make information far more accessible, especially when you consider that the AI doesn't actually have eyes either.

Well, I wasn't referring to just websites. Any software you make is probably going to have some kind of accessibility issues. For example, does your app have color cues for anything? Colorblind people may have an issue with that and so you need to take that into consideration and make the app colorblind friendly as well. It's virtually impossible de-conflicting all the types of colorblindness, so usually people just use icons to tag things instead of colors. This is even more important for things like games where colors indicate critical functions (hence why games sometimes have "colorblind mode")

> First, this is a layout editor first- and foremost. Behind the scenes, React, Redux and slate.js ( http://slatejs.org/ ) is being used.

Would it make sense to have a separate repo for layout editor ?

Not sure what you mean? This is already the case, all cells that you can use in the demo are actually plugins. Check this directory: https://github.com/ory/editor/tree/master/packages/plugins/c...

Reply on news.ycombinator.com