chrs1885 / capable Goto Github PK
View Code? Open in Web Editor NEWUnified accessibility API for iOS, macOS, tvOS & watchOS.
License: MIT License
Unified accessibility API for iOS, macOS, tvOS & watchOS.
License: MIT License
Add md-templates that show up when creating an issue or a pull request. These files should be located in a .github folder
We could use some coding style guide.
I was visiting the Capable CocoaPods page. Then, I was clicking the documentation link.
See the Jazzy HTML documentation generated for the Capable framework.
The documentation link was giving me an error page.
none
Rather than having a single wrapper class for all accessibility settings, rewrite the framework to support a more plugin based approach. This will make it easier (possible) to maintain it. Also, upcoming accessibility settings can easily be provided by new contributors without having them to know anything about the framework's architecture.
When a debugger is attached, I'd like to see logs about certain events (e.g. initializations, notifications) produced by the Capable framework. Furthermore, it would be great expose an API to set my own logger implementation.
By default, the framework uses the default logger implementation build upon os.log. If the debugger is attached, this will log different events (verbose, info, warning, error) coming from the framework code to the console.
If the dev needs to provide her own logger implementation, she can do so by providing a closure.
Also, setting a minimum log level should be supported: if the dev only wants the Capable framework to log warning or errors, she needs to set the log level to warnings.
Custom log closure
var log: (message: String, logLevel: OSLogType) -> () = { message, logLevel in
MyCustomLogger.logToFile(component: "Capable", message: message, type: logLevel)
}
let capable = Capable()
capable.onLog = log
capable.logLevel = OS_LOG_TYPE_INFO
Most SDKs.
These APIs have been added with iOS 14 and are not supported by Capable, yet.
The vision for using this framework is not clear, yet. We could provide an article on how to use Capable together with Firebase Analytics to:
Publish the article as part of the repo docs and on Medium.
Add separate issue markdown templates for bugs and features. When the user clicks the issues tab on GitHub, a selection providing these two types appears.
Please fill out all lines starting with a ๐ when filing a bug to give us an idea of what exactly went wrong.
๐ Impoorting Capable using SPM, at version 2.0.0
๐ The project to build successfully ๐
๐ Error when DifferentiateWithoutColor
observation is created, on iOS platforms :
The NSNotification.Name(rawValue:)
wrapping is too much, just use directly UIAccessibility.differentiateWithoutColorDidChangeNotification
for observer.
๐ Just import Capable 2.0.0 using SPM.
Add notifications for accessibility features that are missing a notification.
While Capable does provide notifications for all accessibility features on iOS and tvOS, it doesn't provide any on macOS, yet. However, by listening to the NSWorkspaceAccessibilityDisplayOptionsDidChangeNotification
we can get informed about changes of accessibility settings.
none
none
Devs who would like to integrate Capable for autoscaling fonts within their apps might not want to use the whole pod but the extension code instead. CocoaPods supports subspecs to only distribute certain parts of the framework.
Add extension subspec to the podspec.
PromiseKit
Users can pair ear aid devices with an iPhone/iPad. The framework could provide the current status as well as send out notifications if the status changes.
The current pairing status can be retrieved by using the hearingDevicePairedEar
property (left, right, both, nil). If the value changes, the hearingDevicePairedEarDidChangeNotification
is sent out.
See https://developer.apple.com/documentation/uikit/uiaccessibility/1648477-hearingdevicepairedear
The API will look pretty much the same as for other features. However, if a device is paired its status will be either left, right, or both. If no device is connected it will be disabled. Therefore, we are going to need some kind of mapping between UIAccessibility.HearingDeviceEar
and String
.
๐คทโโ๏ธ
Drop support for iOS 11, macOS 10.12, tvOS11, and watchOS 3
I was trying to install Capable 1.1.1 by using Carthage.
Carthage should be able to build Capable as per 1.1.0 and before.
I got this error message:
Dependency "Capable" has no shared framework schemes for any of the platforms: iOS
If you believe this to be an error, please file an issue with the maintainers at https://github.com/chrs1885/Capable/issues/new
I found that Capable.xcodeproj
was removed since 11.1.1 in cd49b00, I believe this is the cause of the issue.
Cartfile
github "chrs1885/Capable"
carthage update --platform iOS
The idea of this feature was to identify a user's handicap by checking if one or more accessibility features are currently enabled. You could then replace certain parts of your UI to actually improve it based on this info. However, I decided to focus on wrapping more accessibility feature APIs in the future rather than providing features only a small group of devs are using.
I noticed that the Capable framework appears in the list of schemes when it is added as a SPM dependency when I don't think should be there:
I believe this can be fixed by simply adding .swiftpm to .gitignore (which Point Free had done to address the issue with the Composable Architecture repo: pointfreeco/swift-composable-architecture#1371 & pointfreeco/swift-composable-architecture#1378). However, I don't know if Capable can take this same approach because the file appears in several places (specifically in BuildTools).
iOS 13 is going to introduce new accessibility settings such as
isOnOffSwitchLabelsEnabled: Bool
isVideoAutoplayEnabled: Bool
isOnOffSwitchLabelsEnabled: Bool
Also check for new APIs for other platforms.
As a contributor, I'd like to find some guidelines on how to contribute code to the Capable framework.
Add a contributors.md containing the following info:
Pretty much all OS projects.
When using the Accessibility Inspector for a macOS app, there seems to be another accessibility setting called FullKeyboardAccess
.
Use the .voiceOver
feature as a reference. While notifications do not seem to be available for this accessibility feature, the current status can be requested by using the isFullKeyboardAccessEnabled
property: https://developer.apple.com/documentation/appkit/nsapplication/1428469-isfullkeyboardaccessenabled
The enum value for this feature should be .fullKeyboardAccess
.
none
Further readings:
Code documentation for public APIs
Calculate high contrast text color for specific areas of a given background image.
Get average color of the requested image area. Calculate the high contrast text color based on that color.
class func getTextColors(onBackgroundImage image: Image, imageArea: ImageArea = .full) -> Color? {
Add macOS support.
Client-side grouping of accessibility features by introducing a new type called Handicap.
Today, the framework instance can be initialized by passing in specific accessibility features you are interested in. You can then use this data to send user properties to your backend and add the logic for user segregation there.
I'd like to optionally move this logic to the client by adding certain accessibility features to a Handicap instead. Furthermore, you can define if all features of a Handicap need to be enabled to also set the Handicap's status to enabled. Like with CapableFeatures
, you can initialize the framework by using Handicaps and register them as user properties.
To initialize the Capable instance with a Handicap you can call:
init(withFeatures features: [CapableFeature], name: String, mode: HandicapMode)
The HandicapMode
enum types specifies if either all features need to be enabled to set the Handicap to enabled as well or if only one is sufficient.
The name
param defines the identifier, which can be used to retrieve the handicaps status at any point. It also represents the Handicap within the statusMap
property value.
none
Currently the example application can not be run out-of-the-box. At the current state the application will show an error when compiling that it "cannot find Capable". I think the product of the included Xcode project should either be linked in the "Linked Binaries With Libraries" phase or should be included via Carthage/Cocoapods. The first approach might be more useful since this way the iteration of the Example project could be a lot quicker.
Since most old feature have been removed from Capable 2.0, the main purpose of the framework should be focusing on an unified accessibility API. The WCAG color extension should be moved to its own library project.
With Swift 4.2 (see Proposal SE-0194) a new protocol is introduced called CaseIterable which automatically generates all available cases for an enum. This way the allValues method could be deleted. However I guess we have to wait for the new Xcode 10 to try this new language feature. Whenever I get my hands on the new beta I am happy to help with a PR. I just wanted to open an issue in order to document this.
The Web Content Accessibility Guidelines (WCAG) define best practices for colors used on websites. These guidelines could easily be used to define a WCAG extension on UIColor
.
I'm not too sure about all requirements, yet, so I'm looking for some suggestions. Here is what I came up with initially.
Expose functions to get:
The contrast requirements are based on the text size, background alpha, level of conformance, and font weight.
See https://webaim.org/articles/contrast/
We need to create a UIColor
extension meeting the requirements above. The function names and params are up to the author. We also need to create a separate subspec and extend the existing example projects with a new screen to showcase this feature.
I've seen one project that exposes an API to calculate the contrast ratio for a given color pair: https://github.com/soffes/Color
Since I'm planning iOS 10 support entirely, people can use FontMetrics (>= iOS 11) directly.
Currently, the watch example app only contains a feature statuses view. A second screen should be added since .largerText
is available for watchOS as well.
I would like to see a feature to check, if "Full Keyboard Access" is turned on iOS.
Feature can check if "Full Keyboard Access" is turned on in Settings > Accessibility > Keyboards on iOS.
It would look like:
let capable = Capable(withFeatures: [. fullKeyboardAccess])
let isFeatureEnabled: Bool = capable.isFeatureEnable(feature: . fullKeyboardAccess)
Just the way it works on MacOS. I've tried it on a MacOS destination target and that is exactly what I want and need for iOS.
Nothing found..
Would appreciate any explanation or tips, what's the difference between MacOS and iOS just for understanding.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.