[wp-trac] [WordPress Trac] #47318: Fix the placeholder for the post title field on the classic Edit Post screen

[WordPress Trac]

#47318: Fix the placeholder for the post title field on the classic Edit Post
screen
---------------------------------------+----------------------------
 Reporter:  azaozz                     |       Owner:  azaozz
     Type:  defect (bug)               |      Status:  closed
 Priority:  normal                     |   Milestone:  5.3
Component:  Administration             |     Version:
 Severity:  minor                      |  Resolution:  fixed
 Keywords:  has-screenshots has-patch  |     Focuses:  accessibility
---------------------------------------+----------------------------

Comment (by afercia):

 > The tl;dr: Screens in wp-admin are **not** web page forms. They are
 "application screens". As such they should follow general computer
 applications accessibility standards and guidelines ...

 We agree we disagree :) To me, WordPress is a form-based application which
 uses HTML, which is rendered in a browser, thus all the base Web
 technologies and standards apply.

 I'm not sure I understand how defining WP an "application" makes any
 difference for the users in the practical everyday usage. There are tons
 of usability studies, years of user testing and research related to
 accessibility, specifications, etc., and these general principles don't
 change depending if we call a software "web page forms based" or anything
 else.

 From an usability and accessibility perspective, I listed a few,
 argumented, reasons why a placeholder used improperly is harmful. These
 come from years of user testing and research. That doesn't change whether
 we call WordPress an "application" or a "web form thing".

 Technically, whether a software is web forms based or it's something more
 similar to a desktop application, the way operating systems expose
 information to devices and assistive technologies is the same. Any
 "client", whether it's a browser or other software, communicates to the
 operating system via [https://www.smashingmagazine.com/2015/03/web-
 accessibility-with-accessibility-api/ the Accessibility APIs]. The OS then
 exposes the information to devices and assistive technologies. Anything
 that runs in a browser needs to use proper HTML to make the info passed to
 the Accessibility APIs correct.

 By not applying standards in our development, and by using an HTML element
 / attribute against the specification, we actually sabotage the
 Accessibility APIs thus preventing other software to work correctly and by
 that excluding the persons who use that software.

 Different persons have different needs. In our life, our own needs change
 over time. Standards and accessibility guidelines are the only way to
 build software that aims to be inclusive and usable by everyone. It's not
 just because of a rigid, strict, approach to standards. It's because
 devices and assistive technologies are designed based on those standards.
 When a user interface is designed and built against the standards, devices
 and assistive technologies may not work as expected or not work at all.
 And if they don't work, the users won't be able to use the software. They
 would be ''excluded''. Personally, I'd rather go for inclusion :)

 Not to mention WordPress is the only publishing platform around to have an
 administration interface that is easy to use and partially accessible. It
 is the only chance for many users with diverse abilities to be empowered
 to publish content. To me this 100% matches the WordPress principle to
 democratize publishing, also regardless of the ability level.

 > not exactly WCAG which mostly applies to web pages

 Right again :) As I mentioned previously, the more appropriate standard
 for authoring tools and "applications" that produce web content is
 [https://www.w3.org/WAI/standards-guidelines/atag/ ATAG]. It's more strict
 than WCAG. Glad to switch to ATAG starting tomorrow if you feel that's the
 more appropriate standard :)

 And by the way, the correct usage of the placeholder attribute is not WCAG
 or ATAG: [https://www.w3.org/TR/html52/sec-forms.html#the-placeholder-
 attribute it's HTML] in the first place ;)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47318#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform