Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Reading through the ATAG description I realized we really aren't documenting what we're doing in D8 to improve it's accessibility. There are lots of points that we could add to address the point in A.4.2 to "Document the user interface, including all accessibility features."
I don't think this will be that difficult, but it will require some planning. I do think there should be a top level page for Accessibility under /admin/help - probably just /admin/help/accessibility
There would be some advantages to filling out all three sections:
- About
- Terminology
- Uses
Some sections could possibly have a new Accessibility section that talks about things like:
- ckeditor - #2308515: Document accessibility features in CKEditor
- telephone - #2308581: Document accessibility features in Telephone
- image - #2308549: Document accessibility features in Image
- views - #2308521: Document accessibility features in Views
- views_ui - #2308541: Document accessibility features in Views UI
- system - #1413670: Document 'show row weights' mode
All just making it easier for people to see what we've done to make Drupal more accessible. Folks shouldn't have to look at the issue queue.
Comments
Comment #1
jhodgdonWe do not have a mechanism for adding help at arbitrary paths in Drupal currently. All we can do is add help for *modules*, which is what is listed on admin/help. We proposed having a better help system for Drupal 8, but the proposal died due to lack of interest and/or lack of volunteers to pull it off. So I believe we are now stuck with hook_help(), same as we have been for umpteen Drupal versions. Too bad. Oh well.
So the best you will be able to do is to add a general help section on Accessibility to the System module help, and then also add Accessibility sections to other specific modules that should mention accessibility.
I am not sure about your premise though. The philosophy of Drupal in-code help and documentation is to discuss the state of Drupal *now*, not talk about how it is better, worse, or different from previous versions. (The right place to document the evolution of Drupal is on drupal.org.)
So I would limit the docs added to hook_help() to discussions of how to make a site accessible (things site builders should know), and accessibilty features that are part of particular modules (plus any configuration needed to make them work right). Don't talk about them as "new" features, though -- just document what it is now.
So I've made this a meta-issue. We should add sub-issues for documenting the accessibility features of each separate system or module.
Comment #2
Bojhan CreditAttribution: Bojhan commentedWell we only have to do this for content creation I am guessing. Having it in the help section of Drupal - should be sufficient to meet this requirement. We don't need this to be inline, it merely needs to exist. I hope most of our stuff is self-explanatory though.
Comment #3
mgiffordI'll be talking to the W3C this afternoon. I do think that documenting what we are doing for accessibility is a good thing, but it isn't something that we have to do. We haven't yet signed on to achieve ATAG 2.0 standards yet. I do think there are reasons to do this though at some point. Certainly not till it's formalized though and the community understands the implications.
Bojhan - I was really only thinking of having this in the help section. I don't want to clutter up the interface any more than we have to. However, adding an Accessibility section to the Help page of a module will be a good reminder for everyone who is looking in to learn more about the module.
@jhodgdon - Hopefully we can get more interest in documentation in D9. Some of these issues may need to get pushed off till then.
I only want to talk about what accessibility enhancements are part of Core.
Agreed with just document "what it is now". Also agree about this being a meta-issue to with new child issues being set up for each separate system or module.
Thanks!
Comment #4
Bojhan CreditAttribution: Bojhan commentedSounds like a good idea, there must be some documentation already.
Comment #5
mgiffordI didn't do much more than a first hack, but thought I'd provide on a few of these.
Someone could just search accessibility issues per module and get a review of changes that have been introduced in D8. The System help would have a lot more information.
Comment #6
jhodgdonI've added comments to several of the child issues.
Also fixed typo in issue summary for the Views issue node ID. I suggest actually not trying to maintain the list of child issues in the issue summary. It's easier just to file child issues, mark them as having this as the parent, and they'll show up magically in the sidebar.
Comment #7
mgiffordThanks.. And good suggestion to rely on the list of child issues automagically.
Comment #8
mgiffordComment #9
nod_There is a possibility we'll be adding an accessibility link in the admin to configure site a11y stuff. Might be a good place to put links and stuff, see related issue.
Comment #10
hrezaei CreditAttribution: hrezaei commentedI Really like this issue being worked on. There are great enhancements in drupal 8 that users will find out as they are embedded in the core, and there are some more configurable options that regular users might not notice without any documentation.
Without a proper documentation for accessibility, the normal procedure for the user is like:
Browse the page and figure out how to work with an element and try to resolve the accessibility problem, use google to attempt and see if there's any extra configurations related to the inaccessible area and turn the related option on for more accessible interface.
Comment #11
mgifford@hrezaei Agreed that we need to do more to document this. We need more people looking at what we can document so that they aren't going to have to look to Google first.
Comment #12
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedIs it worth summarizing our known accessibility limitations more proactively, to assist anyone who needs to evaluate Drupal for their organization?
It's great that we document the cool features which work well, but it might be more useful to know what doesn't work. The details are buried in our issue queue, so may not surface quickly to Drupal newcomers.
For example, we have a few icons that don't work in Windows high-contrast mode, without visible fallback text (e.g. the button on search block, contextual-link cogs, and feed icons after #2426967: Feed icon should be a CSS background image not a image file). It would be tough to discover this the hard way after your company intranet goes live.
Comment #13
jhodgdonThat sounds like a good idea. As a start, it might be a good idea to make a drupal.org page about it.
I'm not sure where it would go... but probably it should be linked from
https://www.drupal.org/about/accessibility
Maybe mgifford would have a good idea of where it should be?
Once we've made a list on a d.o page (which maybe could highlight the new features as well as the limitations), maybe we'd have a better idea of where we could/should also add more to the hook_help() documentation within Drupal source too?
Comment #14
mgiffordI do think a page summarizing known issues might be good. Particularly if there are links to issue queues where those may be worked on for 8.1.
We could create a doc page and link to it from https://www.drupal.org/about/accessibility
That page should be re-done with a view to D8 anyways.
@andrewmacpherson - Windows high-contrast mode - so annoying... But important.
Is there a new issue opened up for that? Would be good to have that addressed.
Comment #15
jhodgdon@mgifford: Do you have a good idea where this page about d8 accessibility features and limitations should go in the Documentation book hierarchy?
Comment #16
mgiffordI'm thinking I'd split up Accessible Features in Drupal section to include something specifically Drupal Core.
Comment #29
mgiffordAdding reference to Windows High Contrast Mode.