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

WordPress Trac noreply at wordpress.org
Fri Oct 11 07:32:37 UTC 2019


#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 difference (pretty big difference actually) is how the application
 is used, not the underlying technology.

 I totally agree :) The most important thing is how users use the
 application and their needs, considering users of all abilities. I'm not
 sure I understand what you're actually suggesting. Should WordPress not
 follow the only existing specifications (whether it's WCAG or ATAG) to
 include people of all abilities? How this would relate to the principle of
 an inclusive community that builds an inclusive software to democratize
 publishing?

 To me, at the end any technical detail doesn't really matter. Any software
 should be built do be usable by everyone.

 The web standards movement started about 25 years ago. WCAG are 20 years
 old. If you're suggesting we should ignore all this and go back to an
 inextricable HTML soup with no semantics and no standards at all, please
 just let me know :)

 > Would you say the same for Gmail? A better example: would you say the
 same for Slack? :)

 Those are pretty different software and by the way they use a lot of ARIA
 and scripting to rebuild the semantics and native interaction they destroy
 by not using standards. Just look at the tons of `role` and `aria-*`
 attributes they use, not to mention all the scripting part.

 > why should it look and behave differently just because it runs in a web
 browser?

 Because of HTML :) HTML is literally the language (as in spoken language)
 we use to convey meaning to software and, through software, to users who
 use that software.

 In a previous comment I posted a link to an introductory article on what
 the [https://www.smashingmagazine.com/2015/03/web-accessibility-with-
 accessibility-api/ Accessibility API] are. Maybe worth getting familiar
 with that to have a better understanding of how the whole thing works and
 what would happen when ''not'' following standards.

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


More information about the wp-trac mailing list