> But the barricades had been removed after being vandalized
... is this saying that, like, someone graffiti'd the concrete barriers in front of a collapsed bridge, and they took the barriers away leaving the collapsed bridge accessible?
I'm trying to figure out how to parse this in a way that makes sense to do.
Google puts things on the chopping block due to small userbase or not enough user growth. A very large user base product but which has stagnated should be fine as long as users don't start leavign
Yes and no. Waze provides data points to Google Maps that it wouldn't otherwise have. Like crashes, objects on road, cars pulled over, police speed traps, etc. Waze users provide that data, and Google Maps gets to display it for free. The day when that data input capability is merged into Google Maps completely is when Waze will be shut down and the user experience will slowly be enshitified.
There are 3 different locations in the GitHub repo regarding the security policy: a SECURITY.md file containing instructions to report security vulnerabilities to team@infisical.com — this is employed in other open core repos like Strapi, PostHog, Chatwoot; a security policy on the sidebar that links to the SECURITY.md; and a security section in our README that also links to the SECURITY.md.
There's also an issue template for reporting vulnerabilities as well as you mentioned.
That said, we'll add info to the security page in our docs to contact us regarding vulnerabilities.
You can set the tabindex property on SVG elements just like you can do on HTML, then you could setup an understandable navigation.
The point was that this kind of page is not invisible to screen reader but you still need to think about accessibility and put some effort into it, just like a normal html page.
I don’t doubt it, that kind of issue with navigation sequence is easy to mess up if you don’t prioritize it. I just meant that it being SVG is not inherently invisible to screen readers in the way that Flash was. It still means that they need to put some effort into organizing the navigation.
> Svija pages are fully-readable by screen readers, and you can add special text for each page in Svija Admin, visible only to screen readers.
I tested the accessibility with a keyboard and screen reader. With a keyboard, when you press the tab key, focus should usually go left-to-right, top-to-bottom. On this page the first link you tab to is 'Request Access'. From there the tab key goes backwards, to FAQ, Examples etc, then up to Vibe, Blazing Speed etc. Then it jumps down to the footer, does the same reverse order, then jumps all over the place.
The buttons in the main content to trigger animations aren't focussable at all, so aren't accessible without a mouse or touchscreen.
I explored the page with NVDA (a free screen reader) and found a number of sections and links where what was read out was different to what was shown in screen. It looks like you have a hidden HTML DOM that's exposed to screen readers and I assume this is out of sync somehow with what's on screen? I also got a bunch of links that didn't appear on the screen at all.
Exploring with the NVDA elements list (Insert+F7) shows a lot of junk in the Links list - links with text like 'id1584143858', 'UCmfF3YOMVyRcd0m-WpMUZ2g' etc. The Buttons list doesn't show the animation trigger buttons (because they're not marked up as buttons) and the Landmarks list is empty, meaning no easy way to jump to nav, header, footer etc.
Browser zoom is completely broken. The page looks the same at 500% zoom as it does at 100%.
Accessibility is important, and it's really disheartening when new page-building platforms like this pop up that clearly haven't been audited by an accessibility specialist or run past a disabled person who uses assisitve technology, especially when they specifically give the impression they're accessible as the FAQ answer does
I agree wholeheartedly that accessibility is important, but I can't devote engineering resources to it until I have a product that's compelling in its own right.
Right now I'm just trying to make an interesting platform to explore what's possible with SVG.
Please believe me that when we are able to move forward, accessibility is very high on our priority list.
For a prototype, sure, accessibility might not be top of the list. But everything about the way this is advertised makes it sound like a production-ready product ('it's a stable, rock-solid product') and your FAQs are actively misleading people by implying that it produces accessible output.
It's also orders of magnitude harder to make an inaccessible product accessible than it is to build it in an accessible way in the first place
> "It's also orders of magnitude harder to make an inaccessible product accessible than it is to build it in an accessible way in the first place"
I see so many developers these days make this mistake not only with accessibility, but also with security ("We'll make it secure once it works"; and then it never happens for whatever reason, and by the time it becomes of critical importance it'd take a near complete re-write to "make it secure"), or cross-platforming ("We'll port it to other platforms after we complete the Windows version"; and then down the road they discover they've built on top of a ton of Windows-only middleware and support libraries, painting themselves into a Windows-only corner they cannot escape without a near total re-write). Planning / thinking ahead is a super-important part of the design stage for pretty much any but the simplest of software.
I understand your point. From my point of view, people who visit our site are mostly people whom I've had some contact with or who read about us in a context like HN, so I don't feel people are being misled.
I could be more clear about the product being a prototype — we talked about it amongst ourselves, and decided that it would be better to be as positive as possible in presenting the product.
I seriously doubt that anybody who uses it will be confused in thinking they're building something they're not.
I have a hypothetical question — where does one draw the line when introducing a new technology? A text-based website can be fully accessible, but a movie is not held to the same standards. You don't (as far as I know) create a separate version of a movie with less flickering, or less movement, to enable more sensitive people to be able to enjoy it.
If I am creating a new type of technology that enables animation or other effects, I feel as though I am responsible to handle accessibility as well as possible, but without sacrificing the final product.
I'm probably repeating myself at this point… if I had my way, I would be writing a new editing program to produce hybrid SVG/HTML pages, where the accessibility and other text-oriented issues wouldn't even come up.
However, I don't have the time or the funding right now to write a new editor, so I'm attacking it as best I can with the only program that works, Adobe Illustrator.
IF I can get users, and IF I can get funding, then it will be relatively easy to add accessibility features. Despite what you say about orders of magnitude harder to add accessibility after the fact, these pages are relatively simple.
Right now I could write a script to convert SVG to HTML based on text size and placement on the page. I haven't done it because there are more basic issues like page resizing that need attention, and because I felt that building animation would be more likely to generate interest than saying "look, you can build boring SVG sites that are completely accessible!"
Anyway, I appreciate your taking the time to write. I will try to include more context in our future communication.
Along with the "What about accessibility?" FAQ answer being misleading about the current state, I have two additional concerns:
- Special text only for screen readers: This should not be a primary method of making a site accessible. Hidden text is often incorrect, or maybe it was correct and then someone updated the page and it no longer matches. Out-of-site, out-of-mind is unfortunately often true in this case, and should really be more of a last resort.
- Accessibility is about so much more than screen readers. My first concern for a platforms like this is people who struggle with animations - either feelings of vertigo or nausea, or just finding movement very distracting. Are prefers-reduced-motion settings respected? Does this encourage authors to create content in a way that has a minimal motion fallback that still works? Is it easy for users to stop animations?
Unfortunately, the accessibility challenges here are significant. I'm sure work will be done later to try and improve it, but you will be limited by previous decisions to patching in solutions as best you can. And that rarely results in a truly usable, accessible experience.
I think OP means that new hires are receiving actual spearphishing emails from attackers outside of the company, not that they're testing them by sending fake spearphising emails. (I misread it as the latter at first too)
I'm not sure if they ever did this during onboarding, but my former employer would regularly run fake spearphishing campaigns to raise awareness about spearphishing.
The number of people who regularly fell for it was worrisome. Falling for it meant auto-enrollment in a mandatory security awareness training. Failing to take the training would result in deactivation of the individual's network credentials.
I don't know if these campaigns are actually effective at changing people's behavior, but they certainly revealed how effective spearphishing is.
> Peanut butter is available now, but not that popular
I might be an outlier but my family eats peanut butter all the time, and you wouldn't have any trouble finding it even in small local shops. Peanut butter and j(elly|am) sandwiches are less popular but I maintain that they're America's greatest export.
DVLA systems seem to be an absolute mess, and many public-facing systems are still using the DirectGov styling (which was replaced by GOV.UK in 2012). A lot of their services are completely unavailable overnight from 7pm-7am. So if you sell a vehicle on the last day of the month and go to register the sale after 7pm, bad luck - you're getting charged another month of vehicle tax.
PaaS ran on AWS anyway, so it wouldn't be Amazon (I would guess? Unless they think they can charge more/upsell by departments procuring directly from them). Perhaps Google or MS were upset that by PaaS running atop AWS, AWS became the de facto 'official' cloud service for government?
