Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Draft how-to section about building custom widgets #73

Open
mcking65 opened this issue Aug 12, 2016 · 5 comments
Open

Draft how-to section about building custom widgets #73

mcking65 opened this issue Aug 12, 2016 · 5 comments
Labels
Practice Page Related to a page within the practices section of the APG

Comments

@mcking65
Copy link
Contributor

mcking65 commented Aug 12, 2016 •
edited
Loading

When working on this issue, there is some old content that may be useful in the file aria-practices-DeletedSectionsArchive.html.
The relevant section can be seen here:
https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#accessiblewidget
@mcking65 mcking65 modified the milestones: 1.1, 1.1 APG Release 2, 1.1 PR Aug 12, 2016
@mcking65 mcking65 changed the title Draft section on building custom widgets Draft guidance section about how to build custom widgets Aug 13, 2016
mcking65 added a commit that referenced this issue Aug 14, 2016
@mcking65
Removed sections that require major rework to fix incorrect guidance.
eabf6ca 
In addition to the below, This commit also moves the landmark section after the example section.

Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html
and created associated issues for drafting new versions.
1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue #73.
2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section.
3. Section "Relationships" and raised issues #74, #75, #76, and #77.
4. Section "Managing Dynamic Changes" and created issue #78.
5. Section "Presentation Role" and created issue #79.
6. Section "Form Properties" and created issue #80.
7. Section "Drag-and-Drop Support" and created issue #81
8. Section "Math" and created issue #82.
9. Section "Reusable Component Libraries" and created issue #83.
10. The following 4 Appendix sections related to background on ARIA and created issue #84
A. Background on WAI-ARIA
B. Filling the Gaps for Content Delivered to Desktop Browsers
c. Building Accessible Applications with WAI-ARIA
D. Reasons for Adopting WAI-ARIA
11. The following design patterns:
A. Accordion and updated issue #53.
B. Autocomplete and updated issue #31.
C. Combobox and updated issue #31.
D. Datepicker and updated issue #57
E. Dialog (Non-Modal) and updated issue 59.
F. Dialog (Tooltip) and added issue #85.
G. Landmarks and added issue #86.
H. Popup Help (aka Bubble Help) and added issue #87.
I. Rich Text Editor and added issue #88.
j. Site Navigator - General and added issue #89.
K. Site Navigator - Tree and added it to issue #89.
L. Site Navigator - Tabbed Style and added it to issue #89.
M. Tree Grid and added issue #91.
N. Wizard and added issue #92.
@mcking65 mcking65 modified the milestones: 1.1 PR, 1.1 APG Release 2, 1.1 Q4 PWD Aug 15, 2016
tatermelon pushed a commit to tatermelon/aria-practices that referenced this issue Aug 19, 2016
@mcking65 @tatermelon
Removed sections that require major rework to fix incorrect guidance.
572cdf3 
In addition to the below, This commit also moves the landmark section after the example section.

Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html
and created associated issues for drafting new versions.
1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue w3c#73.
2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section.
3. Section "Relationships" and raised issues w3c#74, w3c#75, w3c#76, and w3c#77.
4. Section "Managing Dynamic Changes" and created issue w3c#78.
5. Section "Presentation Role" and created issue w3c#79.
6. Section "Form Properties" and created issue w3c#80.
7. Section "Drag-and-Drop Support" and created issue w3c#81
8. Section "Math" and created issue w3c#82.
9. Section "Reusable Component Libraries" and created issue w3c#83.
10. The following 4 Appendix sections related to background on ARIA and created issue w3c#84
A. Background on WAI-ARIA
B. Filling the Gaps for Content Delivered to Desktop Browsers
c. Building Accessible Applications with WAI-ARIA
D. Reasons for Adopting WAI-ARIA
11. The following design patterns:
A. Accordion and updated issue w3c#53.
B. Autocomplete and updated issue w3c#31.
C. Combobox and updated issue w3c#31.
D. Datepicker and updated issue w3c#57
E. Dialog (Non-Modal) and updated issue 59.
F. Dialog (Tooltip) and added issue w3c#85.
G. Landmarks and added issue w3c#86.
H. Popup Help (aka Bubble Help) and added issue w3c#87.
I. Rich Text Editor and added issue w3c#88.
j. Site Navigator - General and added issue w3c#89.
K. Site Navigator - Tree and added it to issue w3c#89.
L. Site Navigator - Tabbed Style and added it to issue w3c#89.
M. Tree Grid and added issue w3c#91.
N. Wizard and added issue w3c#92.
@mcking65 mcking65 modified the milestones: 1.1 PR, 1.1 Q4 PWD Dec 12, 2016
@mcking65 mcking65 changed the title Draft guidance section about how to build custom widgets Draft how-to section about building custom widgets Jan 25, 2017
@mcking65 mcking65 removed this from the 1.1 APG Release 4 milestone Aug 14, 2019
@Jefferydo
Copy link

Where can I find the discussion about removing that now-archived section from APG 1.1, "General Steps for Building an Accessible Widget with WAI-ARIA"? I'm contemplating something similar for internal training, and wondering what problems people identified with the approach. The new how-to section is structured quite differently.

@mcking65
Copy link
Contributor Author

I don't know that we have a record of discussion that would be very enlightening. At that time, we removed large chunks of content that required significant revision in order to be accurate. Rewriting that content has not bubbled up the priority list over the last 6 years. It would be a significant effort, and we would need someone with the desire, time, and knowledge to take on the project.

If you would like to work on it, the APG task force could support the work with feedback and reviews. Given the size of the project, I'd recommend starting with an outline before drafting content so we could first align on the objectives and structure.

@Jefferydo
Copy link

Thanks. I'm guessing it's not a priority since the steps don't don't reflect how people actually use APG.

  1. Pick the widget type (role) from the WAI-ARIA taxonomy
  2. From the role, get the list of supported states and properties
  3. Establish the widget structure in the markup (parent/child)
  4. Repeat steps 1-3 for the children of the parent
  5. Establish keyboard navigation of the widget and plan for how it will be navigated to within the document
  6. Apply and manage needed WAI-ARIA states in response to user input events
  7. Synchronize the visual UI with accessibility states and properties for supporting user agents
  8. Showing and Hiding Sections in a Widget
  9. Support basic accessibility, such as alternative text on images
  10. Establish WAI-ARIA relationships between this widget and others
  11. Review widget to ensure that you have not hard coded sizes
  12. Compensate for Background Images when in High Contrast Mode
  13. Test with User agent, Assistive Technology, and People with disabilities

Users still need step 1 (what is this thing) but once they're at the APG pattern there's no concept of steps and I'm not sure it's helpful. The Custom Component Ally Development Checklist from Using ARIA has the same goal without prescribing a workflow.

Perhaps it's necessary for edge cases, like a variant of a role with some additional features? Thing is, I have yet to come across a widget that isn't defined in APG. I'd kill to read a discussion re the completeness of APG's coverage of widgets, and which scenarios require extending the pattern recipes. I recall a guru at a conference saying something like "if you can't find your widget in APG, you need to reconsider your widget". It's a grey area for me.

@JAWS-test
Copy link

I would like it very much if there was this content again. I do not think that every widget is present in the APG. Besides, there are still widgets without example implementation in the APG.

I have one comment on item 12:

  • Background graphics are now displayed by all relevant browsers, to my knowledge, when High Contrast Mode is on.
  • but it would be important that the element is displayed correctly in High Contrast Mode (i.e. use of colors should be checked, also use of HTML elements like a with href or button or other visual markers indicating controls)

@Jefferydo
Copy link

I would like it very much if there was this content again. I do not think that every widget is present in the APG.

Well step one is picking an existing role.

@mcking65 mcking65 added Practice Page Related to a page within the practices section of the APG and removed how-to section labels Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Practice Page Related to a page within the practices section of the APG
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mcking65 @Jefferydo @JAWS-test