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.

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

Consider drafting rich text editor design pattern #88

Open
mcking65 opened this issue Aug 13, 2016 · 6 comments
Open

Consider drafting rich text editor design pattern #88

mcking65 opened this issue Aug 13, 2016 · 6 comments
Labels
question Issue asking a question

Comments

@mcking65
Copy link
Contributor

The APG 1.0 draft of guidance on the topic of rich text editors is not especially useful when working on this issue. The most helpful part are the links to implementations of rich text editors. Since rich text editing is tremendously complex, and since includeing this functionality is a common need, and since ensuring such functionality is accessible, the most useful guidance may be to point authors elsewhere.

The APG 1.0 draft is 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#richtext

@mcking65 mcking65 added this to the 1.1 APG Release 2 milestone Aug 13, 2016
mcking65 added a commit that referenced this issue Aug 14, 2016
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.
tatermelon pushed a commit to tatermelon/aria-practices that referenced this issue Aug 19, 2016
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 added the question Issue asking a question label Jan 19, 2017
@carmacleod
Copy link
Contributor

Please be sure to keep Ctrl+M as the recommended "Toggle Tab Mode" keystroke:

Provide a button in the menu to toggle the use of Tab between the two modes. If this button is used, then Control + M is recommended as a keyboard shortcut to toggle the button.

Our code editor is relying on it.

@wendyabc
Copy link

What's the latest on this? Are there plans to add a rich text editor design pattern?

@jnurthen
Copy link
Member

This is currently in the Milestone 1.1 R3. Target for this release is end 2018. However, unless more people step forward to help with APG it is not likely we will be able to get everything targeted for this release done.

@wendyabc
Copy link

Gotcha. What were the issues with the previous rich text editor design pattern (from circa 2016ish)? I'm not finding that feedback in the issue tracker.

@jnurthen
Copy link
Member

It didn't meet the criteria we set for ourselves. Every pattern needs to be reviewed - and an implementation needs to be created. Previously APG patterns referenced 3rd party implementations but we found this was not satisfactory.

@wendyabc
Copy link

Understood. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Issue asking a question
Projects
None yet
Development

No branches or pull requests

4 participants