> The current file format for Kindle purchases, AZW, is just MOBI + DRM.
Not these days it isn't. They built a custom format to support additional features some time ago, KFX[1].
1,114 karma · joined July 19, 2015
Not these days it isn't. They built a custom format to support additional features some time ago, KFX[1].
I don't disagree, but the results are widely variable with different TRRS I/O across different soundcards. E.g. on a MacBook, the EarPods probably sound great, with a good level of gain and plenty of headroom. On a Lenovo Thinkpad, they sound hissy and terrible because you have to turn the gain all the way up.
> I think my yeti actually sounds worse at it cost 3 times as much.
Something is probably wrong if this is the case. Which is understandable; a USB microphone that's not attached to your person requires some positioning and mic technique that you don't have to think about with the inline mic on the EarPods.
If you use `-vn` and `-acodec copy` (I use both although not sure `-vn` is strictly necessary), you can demux the audio from the video in the same format it is already in. Of course, you're extracting to wav so not transcoding, but copying may be faster/use less space.
From the repo's README:
> We have 16 open source custom elements:
It's feasible that GitHub also have some components that are temporarily or permanently private. Having one repo per component may help to remove the need for that distinction among GitHub developers, who don't have to first check whether to import a component from a public or internal repo.
You don't need a Windows machine or Visual Studio license to use VS Code, which is both cross-platform and free.
I can confirm the OP's experience albeit in a different country (Mexico). In some regions, I haven't been in a single street taxi with working seat belts. Indeed, I've been in some private cars without them as well, or with more physical space for passengers than there were seat belts available.
Uber vehicles, though, have always provided those safety features. Some drivers work as both street taxi and Uber drivers (as they frequently cross into or live in regions without Uber but drive people to places that have it), so that quality assurance can trickle down in some cases. It honestly goes beyond seat belts though; a Uber car is more likely to have AC, electric windows, etc. than your average taxi, even in ridiculously hot parts of the country.
> So we created a Firefox developer account, submitted our extension, and girded ourselves for another rough ride.
Again, if the permissions had been fixed by this point, and Google had accepted it, why would you assume a rough ride from Mozilla?
It was a nonprofit-style project without much wiggle room. We wanted to prove that an idea would or would not work in a small amount of time, which happily overlapped with the fact that the target environment for the device wouldn't require long periods of battery life. I'm happy to say that the project was a success so who knows, maybe one day we'll have someone port it to C and continue from there.
Sorry I can't be more specific.
I'd say the biggest pain points for me (unless I'm missing something/they've added more stuff recently) were created by the lack of support for what feel like production standards in software development. For example, the logging library is a toy, and unit testing is non-existent unless you isolate all your CircuitPython-specific code and run tests on your dev machine using CPython.
Unless you live inside these environments, an easier option would be rclone[1]. I use it on a regular basis to sync large loads to Digital Ocean Spaces, including its bandwidth limiting schedule to avoid saturating the residential uplink at inconvenient times.
It already is to some degree. E.g. I have an application on my iPhone which reads the value of bills (in various currencies) with no noticeable delay, and another that can act as a colour detector although that is less reliable; maybe more useful if you want to know which is the light vs dark thing.
As somebody who has experienced the described behaviour, I can empathise because it is super annoying. But this isn't a particular good point with which to illustrate it. If you're doing any sort of work on one or more remote servers that shouldn't be accidentally terminated like a large data transfer, you should be backgrounding it with screen or similar. Even for users without the idel connection dropping as described, the Internet can still fail.
They implement their own. But the browser also has responsibilities in this area, to construct an accessibility tree from the DOM which screen readers can parse.
Nothing in this space is really mature yet, but there are some efforts to make it a reality. The ARIA-AT project[1], which aims to test assistive technology support for various WAI-ARIA and HTML constructs, is aiming to automate its testing across multiple screen readers [2]. NVDA, the free and open source screen reader mentioned in the article, also includes some integration-style tests[3].
[1] https://github.com/w3c/aria-at [2] https://github.com/w3c/aria-at/issues/349 [3] https://github.com/nvaccess/nvda/tree/master/tests/system
This isn't true, at least not enough to be useful. The majority of screen readers present web pages in a kind of virtual buffer, which users can browse with the arrow keys and other shortcuts (e.g. H to jump by heading). In this mode, the majority of screen readers don't fire focus events to let you know, "hey, your screen-reader-only element has been hit". You would be limited to:
1. users operating a screen reader which does fire focus events;
2. trying to highjack scroll events for this purpose; and
3. less technically-inclined users (read: beginners) who move through the page with Tab/Shift+Tab before they've learned the other keystrokes their screen reader offers.
It's separation, because it introduces the chances of an inequitable experience being created as the "customised" version for screen reader users drifts out of sync. This may not even be down to anything malicious; plenty of companies create mobile-friendly versions of websites and apps, only to find that as years go by, they no longer have the budget to facilitate their upkeep. Far from assigning them to the trash heap of history, these often continue to be provided, offering a substandard experience, and this is despite companies having so much data available about high mobile usage. The chances of it happening to an accessibility-specific version are higher because the likely user take-up is lower, and as this post and thread indicate, speciality skills are often required to make a good job of it. Not like responsive web design, where experts are ten a penny.
There are other reasons this approach is flawed, of course:
1. Screen reader users aren't the only disabled people out there. Heck, even within that group, there are those who use the software as an absolute necessity, and others who use it in addition with other assistive tech like speech recognition or a magnifier. Nobody in their right mind is going to create a separate experience for every subset of disabled users. Even if they did, how would they be surfaced?
2. Some people are only temporarily disabled, e.g. because of an injury. They don't have the lifelong feel for how to look for accessibility settings or separate modes, so they aren't likely to benefit from a shiny accessible version. Making your main product inclusive prepares for this.
3. The aim should be to allow customisations to be included which aren't intrusive to those who don't need them, e.g. via techniques like WAI-ARIA[1] which allow additional context to be added for screen reader users while remaining invisible to everyone else.
This is a different case for two significant reasons:
1. Utilising purely sensory references in web materials is a violation of WCAG success criterion 1.3.3, Sensory Characteristics (level A)[1]. Naturally, if you're physically brailling something, it's probably not web content but the point still stands: if your web page tells people to press the red button on the left it's not accessible to some.
2. By including alternative instructions in some form/format (or just making them inclusive from the start), you're not asking anybody to out themselves as having a permanent or circumstantial disability. You're just preparing for the case that they do. This is assuming the alternative option is available to everyone (e.g. on a web page or as a physical braille sign), rather than as something that is locked away and must be explicitly requested.
[1] https://www.w3.org/WAI/WCAG21/Understanding/sensory-characte...
Quite possibly. But there is an argument for that being voluntary rather than mandatory, even if that decision is provided via a switch in OS-or-screen-reader-level settings. But then there are questions such as:
- Should such a setting be switched on by default?
- What sort of users are likely to enable/disable it?
- If there is any correlation between level of technical skill and privacy awareness, will results be skewed towards the users with lower levels of technical knowledge?
- If a product team uses the data to solicit feedback from users who are detected to be running an assistive technology, but quote "power users" unquote have turned off that detection, again, will that feedback be representative?
Anecdotally, I will say that after working with some iOS development teams where this behaviour is natively available, cases which rely on an explicit detection of VoiceOver still seem rare. Whereas, use of features like accessibility label overrides without an explicit check are used a lot. On the other hand, it's becoming much more common to perform explicit checks for more visually-oriented accessibility features, like reduced motion or high contrast, some of which can even be carried out on the web now.
You could be right, but keep in mind that this may not significantly lower the amount of time required for developers to understand and remediate problems. Users have wildly differing levels of technical experience, so you may end up with plenty of feedback that you then have to spend hours understanding, sorting, de-duplicating and following up on.
Not to mention the fact that, bluntly, users who aren't being paid as "experts" just may not be that willing to shit all over your product. I have encountered more than one case of a limited subset of screen reader users reporting a positive experience with a component which broke every rule in the book, and caused very real problems for users outside of that core group.
I agree with this. I will say that developers who are 100% unwilling to entertain changes to their "main" UI to accommodate accessibility are in the clear minority. But even the most well-meaning devs and designers will ask questions like, "could we just do this for screen reader users ...?". It's a slippery slope from there, with technical debt, legacy implementation and ghetto user flows all the way down.
NVDA, mentioned prominently in the article as a free and open source screen reader, has a floating-window-style speech viewer. I sometimes use it when demonstrating a screen reader user's experience of a particular component when asked to share my audio, because slowing down the screen reader to a rate that everyone on the call will understand will also make the meeting much longer.
JAWS also has a speech history viewer, and there are keystrokes to dump VoiceOver speech as text and audio files.
The author may be interested in the ARIA-AT project[1], which aims to thoroughly test assistive technology support for WAI-ARIA and HTML constructs. It's still a relatively young effort, but the community group is open and always happy for participation.
Sonos also supports AirPlay, as well as DLNA/UPnP rendering. So for example you can set a Sonos speaker as the output device, wirelessly, in the latest nightly builds of VLC[1].
I'm not sure how this can be true. Their terms of service specifically ban users from reverse engineering unofficial parts of the product.
Either way, I'd be interested to know how it actually works.
I have an unusual interest in this topic. I grew up in the UK, and that's just how people do the dishes. Or at least, the people in my orbit. So when I see that on TV, it's completely normal.
But, I now live in Mexico and everybody uses some variation of your method (again, everybody with a "people I've observed washing the dishes" qualifier). I find it completely bizarre.
Probably plenty of places. E.g. UK has the fish finger:
I can, but that's probably because I partially rely on audiobooks (in addition to eBooks with text-to-speech) because of blindness.
> There were once radio plays, but with the demise of radio, audio plays barely exist nowadays in English
Agreed that unfortunately, the amount of radio plays being produced has dramatically decreased (excuse the pun). But I mostly notice this in English speaking nations other than the United Kingdom like Canada and the US. In the UK, radio drama is still very much alive, with the BBC and third parties like Big Finish producing a ton of great content.
For sure. If your website does work in edbrowse, it may imply that you have a decent chance of making it accessible because it doesn't use a ton of dynamic interactions or page updates etc. But it doesn't guarantee it. You could still have issues with heading hierarchy, communication of control state and other factors. In some cases, edbrowse may even lull someone into a false sense of security, because it simply can't present certain aspects of your page. But when displayed in a mainstream browser, they may be inaccessible.
In a nutshell, it's unlikely that you can draw any meaningful conclusions after testing with edbrowse, be they about the accessibility of the page or the typical experience of a blind user on the web.
Completely agree with this (and your other comments re: interpretation). In the real world, it's rare for content and data to be as simplistic as the example described here, and presenting it in an inclusive fashion which allows all users to make their own conclusions is the key.