novoda / accessibilitools

UI tools to help make your Android app accessible.

novoda

This repo contains information that is common to all Novoda's Open Source projects.

accessibilitools's Issues

Fix develop/master branch confusion

I think we need to have master representing latest releases only, and be the visible branch on the home page.

But I was hoping that we could set the default PR base branch to develop.

Is it possible to have these different? If not, more important to keep master as the main branch, so visitors see release version/docs.

New logo/icon

Hi, I am a graphic designer, I want to help others in graphic design.

After I reviewed your project, you have no logo on this project. Therefore I want to contribute to this project by creating a new logo / icon. what do you think?

Add push access for ataulm

👋 Can I have contributor push access on this repo please? It'll be easier for me to work on and raise PRs.

Maybe at the same time protect the main branch so that only admins can push to it (I'm not asking for admin).

Deprecate Action-related classes after verifying whether they are now redundant

#28 added an alternative way to specify custom actions. This should be tested by creating a local release of accessibilitools and determining whether the change causes any issues in any current usage of the project.

If it's fine, then we can deprecate these classes:

• Action
• Actions
• ActionsAlertDialogCreator
• ActionsAccessibilityDelegate

when this issue is complete, a new issue should be defined and linked here to delete/remove those classes (probably prior to shipping 2.0 but can be discussed).

Investigate whether a Menu XML resource + MenuItemClickListener could be a viable way to specify custom actions

Inflating a menu and providing a MenuItemClickListener might be easier for the users instead of having to specify each Action individually (a unique ID, String and runnable for the action) for ActionsAccessibilityDelegate and ActionsAlertDialogCreator.

In my understanding, this would involve creating an implementation of at least Menu (24 methods) and MenuItem (41 methods) such that a menu inflater can inflate the menu using a given XML Menu resource.

For us, the required attributes from the Menu xml would include title (already required) and id (not sure if required, but for us, we need to map it to an action). There would be other attributes available that would just be ignored, but this is already the case with other menu-based widgets like BottomNavigationView.

Here's quite an extreme example of building a set of custom actions with the current API, where depending on the item, some actions are excluded from the list of available actions. In my mind, with a Menu-based implementation, it would be a case of inflating all actions, then disabling/removing the invalid ones.

Before starting on this issue, please discuss here (perhaps after a little investigation) to agree approach, esp. for API.

Need to recreate ActionsDialogCreator per set of Actions

Because the Actions are passed into the ctor, you need to create a separate ActionsDialogCreator to create a dialog with a different set of actions.

It'd make more sense if the actions were passed to the create() method instead, where it's needed.

Fix Pull Request Builder or ensure it's active and working

Any disadvantages on adding a PRB on this repo?

Deprecate usage hint methods in ActionsAccessibilityDelegate

Revert the deletion of the setClickLabel and setLongClickLabel methods from ActionsAccessibilityDelegate.

Mark them as deprecated, and internally, delegate to UsageHints object (which is already there).

This will allow users to upgrade from 1.4.0 - 1.5.x without forcing any API changes.

Add support for AccessibilityNoHideDescendents for API pre-19

Needs further testing, but this is in use on a project and is generic enough to be useful for others.

Would need to compare on pre-19 devices which don't have access to View.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDENTS and whether it does in fact replicate that behaviour correctly (or close enough).

package com.novoda.accessibilitools;

import android.view.View;
import android.view.ViewGroup;

import com.novoda.accessibilitools.R;

public class AccessibilityImportance {

    /**
     * View.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDENTS is min SDK 19.
     * This sets iterates through View tree and sets each one to NO.
     * <p>
     * Alone, that would be destructive, because we wouldn't be able to restore the original state.
     * Instead, we also store the original state as a tag on the view, so it can be restored.
     */
    public static void recursivelySetNotImportant(View view) {
        view.setTag(R.id.important_for_accessibility, view.getImportantForAccessibility());
        view.setImportantForAccessibility(View.IMPORTANT_FOR_ACCESSIBILITY_NO);
        if (view instanceof ViewGroup) {
            ViewGroup viewGroup = (ViewGroup) view;
            for (int i = 0; i < viewGroup.getChildCount(); i++) {
                recursivelySetNotImportant(viewGroup.getChildAt(i));
            }
        }
    }

    public static void recursivelyResetImportanceOrAuto(View view) {
        Object tag = view.getTag(R.id.important_for_accessibility);
        int importantForAccessibility = tag != null ? (int) tag : View.IMPORTANT_FOR_ACCESSIBILITY_AUTO;
        view.setImportantForAccessibility(importantForAccessibility);

        if (view instanceof ViewGroup) {
            ViewGroup viewGroup = (ViewGroup) view;
            for (int i = 0; i < viewGroup.getChildCount(); i++) {
                recursivelyResetImportanceOrAuto(viewGroup.getChildAt(i));
            }
        }
    }
}