dialog: Update accessibility notes (#18841)

* Update accessibility notes

See the updates in https://www.scottohara.me/blog/2019/03/05/open-dialog.html

* Update after review

Co-Authored-By:  Estelle Weyl <[email protected]>

* Apply suggestions from code review

* Update files/en-us/web/html/element/dialog/index.md

* Edits per Scott

I couldn't commit your edits for some reason, so had to re-edit.

Co-authored-by: Estelle Weyl <[email protected]>

files/en-us/web/html/element/dialog/index.md

@@ -85,7 +85,15 @@ This element includes the [global attributes](/en-US/docs/Web/HTML/Global_attrib
 
 ## Accessibility considerations
 
-The `dialog` element still has [usability issues with some forms of assistive technology](https://www.scottohara.me/blog/2019/03/05/open-dialog.html). Because of this, it is advised to use an interim solution such as [a11y-dialog](https://a11y-dialog.netlify.app/) as support continues to improve.
+To ensure accessibility for users of Safari versions below 15.4, consider using a polyfill such as [a11y-dialog](https://a11y-dialog.netlify.app/) as earlier implementations of the `<dialog>` element had [usability issues with some forms of assistive technology](https://www.scottohara.me/blog/2019/03/05/open-dialog.html).
+
+When implementing a dialog, it is important to consider the most appropriate place to set user focus. Explicitly indicating the initial focus placement by use of the [autofocus](/en-US/docs/Web/HTML/Global_attributes/autofocus) attribute will help ensure initial focus is set to the element deemed the best initial focus placement for any particular dialog.  When in doubt, as it may not always be known where initial focus could be set within a dialog, particularly for instances where a dialog's content is dynamically rendered when invoked, then if necessary authors may decide focusing the `<dialog>` element itself would provide the best initial focus placement.
+
+Ensure a mechanism is provided to allow users to close a dialog. The most robust way to ensure all users can close a dialog is to include an explicit button to do so. For instance, a confirmation, cancel or close button as appropriate. Additionally, for those using a device with a keyboard, the <kbd>Escape</kbd> key is commonly expected to close modal dialogs as well. By default, a `<dialog>` invoked by the `showModal()` method will allow for its dismissal by the <kbd>Escape</kbd>.  A non-modal dialog does not dismiss via the <kbd>Escape</kbd> key by default, and depending on what the non-modal dialog represents, it may not be desired for this behavior. If multiple modal dialogs are open, <kbd>Escape</kbd> should only close the last shown dialog.
+
+The `<dialog>` element is exposed by browsers similarly to custom dialogs using the ARIA [role="dialog"](/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role) attribute. `<dialog>` elements invoked by the `showModal()` method will have an implicit [aria-modal="true"](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-modal), where as `<dialog>` elements invoked by the `show()` method, or rendered by use of the `open` attribute or changing the default `display` of a `<dialog>` will be exposed as `[aria-modal="false"]`.  It is recommended to use the appropriate `showModal()` or `show()` method to render dialogs.
+
+Ensure your dialog implementation doesn't break expected default behaviors and follows proper labeling recommendations.
 
 ## Usage notes