search

dart-lang / pub-dev

The pub.dev website
https://pub.dev
BSD 3-Clause "New" or "Revised" License
801 stars 147 forks source link

Feature Request: Flutter Favorite program should include accessibility requirements #3848

Open nilsreichardt opened 4 years ago

nilsreichardt commented 4 years ago

Problem

Many packages have no accessibility support (Text scaling, screen reader, etc.), which is a big problem for me as an app developer. It's my responsibility that our app has accessibility support. There are no quick indicators to know if a package has accessibility support...

Especially the AppStore team pays a lot of attention to accessibility (when it comes to featuring).

Example of problems

Idea

An idea would be a accessibility score to get maintainers more motivated. But the main point of the accessibility score is, that developers can see directly whether the package has accessibility support. I would directly see that flutter_markdown doesn't scale font size --> no accessibility support.

Are there any good solutions to integrate this? Maybe you could scan the package example app 🤷‍♂️

timsneath commented 4 years ago

I love the idea, and in principle we'd eagerly adopt something like this.

The challenge is execution, obviously -- packages are scanned through an automated tool, pana, and we'd need to identify some checks that would support this. Would appreciate ideas from you or others about rules that we could apply here.

Separately, I notice that the Flutter Favorite program doesn't yet include accessibility as an explicit part of its criteria (although it does mention 'usability'). Since this includes a manual review step, it would be viable to include some kind of accessibility test in this award moving forward. I'll raise that with the team for consideration.

sigurdm commented 4 years ago

This is a great idea for the flutter-favorite program. This doesn't really belong on the pub-dev issue tracker. Closing this here. @timsneath do you want to open this in the flutter issue tracker?

nilsreichardt commented 2 years ago

I'll raise that with the team for consideration.

@timsneath Looking 2 years later on the metrics for the Flutter Favorite program, accessibility is not mentioned. There is also no word about accessibility in the "What's next" section, where possible future metrics are mentioned. Does this mean, the team decided against adding accessibility as a metric to Flutter Favorite program for now?

timsneath commented 2 years ago

To my sorrow, this issue has bounced around a couple of trackers but not been picked up by anyone :(

Rather than bounce it around again, I'm going to reopen it here. The Flutter Favorites program has been on a short hiatus due to team changes (folk on leave, transitions), but I think we should just agree that this should be factored into their reviews moving forward. @johnpryan for visibility.

More context: https://github.com/flutter/flutter/issues/67394#issuecomment-705041144

sigurdm commented 2 years ago

So if we believe accessibility can be checked automatically where do we fit these in?

I think the best way be to create a number of lints that warn about inaccessible usage of API (forgetting to fill in onPressed etc. and adding these lints to the flutter default lints).

Then any violated lints would show up in the pana results, and result in a lower score.

Or are there checks that are so special they have to live in pana?

nilsreichardt commented 2 years ago

Or are there checks that are so special they have to live in pana?

If we want to fully cover accessibly, we can't do it automatically. However, I think it's enough for the beginning to just have some lints as you said which effects the pub dev score. I think have some lints shouldn't be that hard, like have always a Semantics.button = true for GestureDector, have always a value for Image.semanticsLabel, check Theme color for contrast, etc. There is already ticket for having accessibility lints: https://github.com/dart-lang/sdk/issues/58251

The TypeScript world has already an accessibly linting package (+10M downloads per week) with these rules:

alt-text: Enforce all elements that require alternative text have meaningful information to relay back to end user. anchor-has-content: Enforce all anchors to contain accessible content. anchor-is-valid: Enforce all anchors are valid, navigable elements. aria-activedescendant-has-tabindex: Enforce elements with aria-activedescendant are tabbable. aria-props: Enforce all aria- props are valid. aria-proptypes: Enforce ARIA state and property values are valid. aria-role: Enforce that elements with ARIA roles must use a valid, non-abstract ARIA role. aria-unsupported-elements: Enforce that elements that do not support ARIA roles, states, and properties do not have those attributes. autocomplete-valid: Enforce that autocomplete attributes are used correctly. click-events-have-key-events: Enforce a clickable non-interactive element has at least one keyboard event listener. heading-has-content: Enforce heading (h1, h2, etc) elements contain accessible content. html-has-lang: Enforce element has lang prop. iframe-has-title: Enforce iframe elements have a title attribute. img-redundant-alt: Enforce alt prop does not contain the word "image", "picture", or "photo". interactive-supports-focus: Enforce that elements with interactive handlers like onClick must be focusable. label-has-associated-control: Enforce that a label tag has a text label and an associated control. lang: Enforce lang attribute has a valid value. media-has-caption: Enforces that <audio> and <video> elements must have a <track> for captions. mouse-events-have-key-events: Enforce that onMouseOver/onMouseOut are accompanied by onFocus/onBlur for keyboard-only users. no-access-key: Enforce that the accessKey prop is not used on any element to avoid complications with keyboard commands used by a screenreader. no-autofocus: Enforce autoFocus prop is not used. no-distracting-elements: Enforce distracting elements are not used. no-interactive-element-to-noninteractive-role: Interactive elements should not be assigned non-interactive roles. no-noninteractive-element-interactions: Non-interactive elements should not be assigned mouse or keyboard event listeners. no-noninteractive-element-to-interactive-role: Non-interactive elements should not be assigned interactive roles. no-noninteractive-tabindex: tabIndex should only be declared on interactive elements. no-onchange: Enforce usage of onBlur over onChange on select menus for accessibility. no-redundant-roles: Enforce explicit role property is not the same as implicit/default role property on element. no-static-element-interactions: Enforce that non-interactive, visible elements (such as <div>) that have click handlers use the role attribute. role-has-required-aria-props: Enforce that elements with ARIA roles must have all required attributes for that role. role-supports-aria-props: Enforce that elements with explicit or implicit roles defined contain only aria- properties supported by that role. scope: Enforce scope prop is only used on <th> elements. tabindex-no-positive: Enforce tabIndex value is not greater than zero.

https://www.npmjs.com/package/eslint-plugin-jsx-a11y

So my suggestion would to leave this ticket open but focus on accessibly lints.

sigurdm commented 2 years ago

There is already ticket for having accessibility lints: https://github.com/dart-lang/pub-dev/issues/2300

I think you linked to the wrong issue...

nilsreichardt commented 2 years ago

I think you linked to the wrong issue...

Oh, yes - thanks for the catch! I fixed it :+1:

sigurdm commented 1 year ago

We still don't think this is the right issue-tracker. But hopefully we will find an owner for this at some point.