Archived
15
23
Fork
You've already forked meta
6

[Governance][Agreement] Add Accessibility as Forgejo value #179

Merged
earl-warren merged 1 commit from fsologureng/meta:a11y-as-value into readme 2023年03月15日 18:03:24 +01:00
Contributor
Copy link

The Forgejo initiative has publicly declared interest in develops a software forge with accessibility concerns, among other features.

Under this premise I propose to add Accessibility as a core value of the initiative:

All Forgejo developments will be made considering the ability
to access of people with disabilities or functional impairment as a condition of
equality of opportunities and inclusion, understanding Accessibility as the
quality of being able to access with assistive technology.

Please feel free to comment, improve, suggest, object or approve this proposal taking into account your own concerns or level of agreement.

The Forgejo initiative has publicly declared interest in develops a software forge with accessibility concerns, among other features. Under this premise I propose to add Accessibility as a core value of the initiative: *All Forgejo developments will be made considering the ability to access of people with disabilities or functional impairment as a condition of equality of opportunities and inclusion, understanding Accessibility as the quality of being able to access with assistive technology.* Please feel free to comment, improve, suggest, object or approve this proposal taking into account your own concerns or level of agreement.
fsologureng changed title from (削除) Add Accessibility as Forgejo value (削除ここまで) to [Governance][Agreement] Add Accessibility as Forgejo value 2023年02月27日 23:59:40 +01:00
Contributor
Copy link

I'm very much in favour of this proposal. As it stands right now, you are the only member of the accessibility team.

My reading is that you would have to have a say in every change.

Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind.

I'm very much in favour of this proposal. As it stands right now, [you are the only member of the accessibility team](https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md#accessibility). My reading is that you would have to have a say in every change. Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind.
MISSION.md Outdated
@ -79,0 +79,4 @@
3. **Accessibility**: All Forgejo developments will be made considering the ability
to access of people with disabilities or functional impairment as a condition of
equality of opportunities and inclusion, understanding Accessibility as the
quality of being able to access with assistive technology.

I think the last part of the sentence coould be omitted, as for instance there are also color schemes that aren't directly related to assistive technology. Also the part "as a condition of" makes the sentence a bit hard to parse imho. Maybe it might read as:

  1. Accessibility: All Forgejo developments will be made considering the ability
    to access of people with disabilities or functional impairment and in the spirit of
    equality of opportunities and inclusion.
I think the last part of the sentence coould be omitted, as for instance there are also color schemes that aren't directly related to assistive technology. Also the part "as a condition of" makes the sentence a bit hard to parse imho. Maybe it might read as: > 3. **Accessibility**: All Forgejo developments will be made considering the ability to access of people with disabilities or functional impairment and in the spirit of equality of opportunities and inclusion.
Author
Contributor

I agree with you. I overlooked that difference. I will do a fix with your suggestion.

I agree with you. I overlooked that difference. I will do a fix with your suggestion.
fsologureng marked this conversation as resolved
Contributor
Copy link

@Ryuno-Ki: Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind.

Without going too much OT I feel that Accessibility should safeguard a11y, which includes checking compliance of the work that is done and identifying improvements.

But imho an important part of the task is to be an 'Accessibility Stimulator' whereby attention for a11y is a natural thing that any project member is expected to take into account. Stimulator gently points that out, when it is at risk to be overlooked.

And if we adopt standardized compliance level and as part of the agile development process there could be an item in the "Definition of Done" checklist of an issue, asking "Did you take Accessiblity into account in your work?".

PS. I also think this should lighten the work of the Accessibity team. They are not responsible to develop the accessibity.

> @Ryuno-Ki: Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind. Without going too much OT I feel that Accessibility should safeguard a11y, which includes checking compliance of the work that is done and identifying improvements. But imho an important part of the task is to be an 'Accessibility Stimulator' whereby attention for a11y is a natural thing that any project member is expected to take into account. Stimulator gently points that out, when it is at risk to be overlooked. And if we adopt standardized compliance level and as part of the agile development process there could be an item in the "Definition of Done" checklist of an issue, asking "Did you take Accessiblity into account in your work?". PS. I also think this should lighten the work of the Accessibity team. They are not responsible to _develop_ the accessibity.
Contributor
Copy link

@Ryuno-Ki: Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind.

Without going too much OT I feel that Accessibility should safeguard a11y, which includes checking compliance of the work that is done and identifying improvements.

Allow me to cite an accessibility consultant

I focus on outcomes for users, not conformance. I focus on empowering teams, not setting up recurring monthly fees. I focus on making organizations self-sustaining, not helping them avoid lawsuits.

> > @Ryuno-Ki: Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind. > > Without going too much OT I feel that Accessibility should safeguard a11y, which includes checking compliance of the work that is done and identifying improvements. Allow me to [cite an accessibility consultant](https://adrianroselli.com/2023/02/audioeye-will-get-you-sued.html) > I focus on outcomes for users, not conformance. I focus on empowering teams, not setting up recurring monthly fees. I focus on making organizations self-sustaining, not helping them avoid lawsuits.
Author
Contributor
Copy link

I'm very much in favour of this proposal. As it stands right now, you are the only member of the accessibility team.

What is the relevance that I am the only member? I don't get it.

My reading is that you would have to have a say in every change.

Well, my effort will be absolutely insufficient if there are no disposition to address this need or without disposition to collaborate with knowledge in this huge task, considering the accessibility grade of code.

Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind.

Me too. That's why I opened the PR.

> I'm very much in favour of this proposal. As it stands right now, [you are the only member of the accessibility team](https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md#accessibility). What is the relevance that I am the only member? I don't get it. > > My reading is that you would have to have a say in every change. Well, my effort will be absolutely insufficient if there are no disposition to address this need or without disposition to collaborate with knowledge in this huge task, considering the accessibility grade of code. > > Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind. Me too. That's why I opened the PR.
Contributor
Copy link

I'm very much in favour of this proposal. As it stands right now, you are the only member of the accessibility team.

What is the relevance that I am the only member? I don't get it.

If you would have veto power (as I was not sure about) that would imply that you would become a bottleneck.

My reading is that you would have to have a say in every change.

Well, my effort will be absolutely insufficient if there are no disposition to address this need or without disposition to collaborate with knowledge in this huge task, considering the accessibility grade of code.

I agree. You're facing an uphill battle :-(

Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind.

Me too. That's why I opened the PR.

We're on the same side, then!

> > I'm very much in favour of this proposal. As it stands right now, [you are the only member of the accessibility team](https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md#accessibility). > > What is the relevance that I am the only member? I don't get it. If you would have veto power (as I was not sure about) that would imply that you would become a bottleneck. > > My reading is that you would have to have a say in every change. > > Well, my effort will be absolutely insufficient if there are no disposition to address this need or without disposition to collaborate with knowledge in this huge task, considering the accessibility grade of code. I agree. You're facing an uphill battle :-( > > Before I can agree, I'd like to get a rough estimate how confident contributors are in developing with accessibility in mind. > > Me too. That's why I opened the PR. We're on the same side, then!
Author
Contributor
Copy link

If you would have veto power (as I was not sure about) that would imply that you would become a bottleneck.

Have you seen anyone in Forgejo willing to let me make a veto? 😆 No one is going to stop doing things no matter how much intention I put into it. It's not my idea, either. It's much closer to @circlebuilder's idea, but probably with a stronger intervention using good words. Either way, without willingness of other members it's totally useless and a waste of time.

For example, accessibility (or UI/UX) concerns has typical responses (no personal questioning, it is just as a general example) when issues arise: They simply choose to delay it to an unknown date or to foist the responsibility of the fix on you or someone else. The result is a lack of improvement or, worse, regression. Because both UX/UI and a11y need a global vision, not a "I'm in a hurry" or "it's not my problem, someone else will fix it", or "Accessibility is not a priority just an enhancement" kind of approach.

Accessibility should be part of the design from the beginning ("Your design is not done if you haven't considered the people who need to use it. It's just not done."), like security and privacy, not as a half-baked fix done too late. Based on the fact that we are a soft-fork, the amount of design done here is not much at the moment, but the amount of legacy bugs is huge. Please see this new Scoped Labels feature, do you think visual aid is a design criterion with accessibility concerns? The criteria is "because look's cool". We're gaining another big problem to fix in this area.

If we could come to a general agreement internally that new designs integrate accessibility concerns from the start, perhaps we could improve accessibility and free people with functional impairments from GitHub. Otherwise, the solution will persist for the privileged ones able to free themselves, which is an elite, and I'm not just talking about people well-sighted, but developers with the skills to find a button that who knows where it is.

> If you would have veto power (as I was not sure about) that would imply that you would become a bottleneck. Have you seen anyone in Forgejo willing to let me make a veto? 😆 No one is going to stop doing things no matter how much intention I put into it. It's not my idea, either. It's much closer to @circlebuilder's idea, but probably with a stronger intervention using good words. Either way, without willingness of other members it's totally useless and a waste of time. For example, accessibility (or UI/UX) concerns has typical responses (no personal questioning, it is just as a general example) when issues arise: They simply choose to delay it to an unknown date or to foist the responsibility of the fix on you or someone else. The result is a lack of improvement or, worse, regression. Because both UX/UI and a11y need a global vision, not a "I'm in a hurry" or "it's not my problem, someone else will fix it", or "Accessibility is not a priority just an enhancement" kind of approach. Accessibility should be part of the design from the beginning (["Your design is not done if you haven't considered the people who need to use it. It's just not done."](https://www.buzzsprout.com/719037/11903986)), like security and privacy, not as a half-baked fix done too late. Based on the fact that we are a soft-fork, the amount of design done here is not much at the moment, but the amount of legacy bugs is huge. Please see [this new Scoped Labels feature](https://codeberg.org/earl-warren/forgejo/src/branch/wip-1.19-release-notes-label/RELEASE-NOTES.md#scoped-labels-https-codeberg-org-forgejo-forgejo-commit-6221a6fd5), do you think *visual aid* is a design criterion with accessibility concerns? The criteria is "because look's cool". We're gaining another big problem to fix in this area. If we could come to a general agreement internally that **new designs** integrate accessibility concerns from the start, perhaps we could improve accessibility and free people with functional impairments from GitHub. Otherwise, the solution will persist for the privileged ones able to free themselves, which is an elite, and I'm not just talking about people well-sighted, but developers with the skills to find a button that who knows where it is.
Contributor
Copy link

They simply choose to delay it to an unknown date or to foist the responsibility of the fix on you or someone else.

That is where a "Definition of Done" may help. Your PR won't be merged, because the work isn't "Done" when Accessibility isn't tackled.

> They simply choose to delay it to an unknown date or to foist the responsibility of the fix on you or someone else. That is where a "Definition of Done" may help. Your PR won't be merged, because the work isn't "Done" when Accessibility isn't tackled.
First-time contributor
Copy link

It has been two weeks which is the recommended wait period and no concern was raised.

It has been two weeks which is the recommended wait period and no concern was raised.
Commenting is not possible because the repository is archived.
Labels
Clear labels
[Decision] Building proposal(s)
We're in a decision-making process, buiding one or more proposals to address the shared aim based on the criteria
[Decision] Gathering criteria
We're in a decision-making process, gathering criteria, considerations and needs
[Decision] Integrating concerns
We're in a decision-making process, working with a proposal, trying to integrate concerns and create modifications/support such that the proposal works for everyone
Accessibility
Relates to Accessibility (a11y) of product, project and process.
Agreement proposal
Forgejo agreement proposal, following a discussion
Communication
Relates to all channels, social media, website, blog posts.
Election
Process of appointing a person into a role or team (if choosing people just for a specific one-time task, use the Entrustment label)
Entrustment
Process of choosing/approving specific people to do a critical/high-impact one-time task (if choosing people for an ongoing role/team, use the Election label)
Governance
Relates to processes, procedures and decision-making.
Meeting
An upcoming team meeting
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo/meta!179
Reference in a new issue
forgejo/meta
No description provided.
Delete branch "fsologureng/meta:a11y-as-value"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?